Rowid의 개념:
rowid는 의사 열이므로 이 열은 사용자가 정의하지 않고 시스템 자체에서 추가됩니다. 각 테이블마다 rowid 의사 열이 있지만 ROWID 열의 값은 테이블에 물리적으로 저장되지 않습니다. 단, 다른 컬럼과 동일하게 사용할 수 있으나, 컬럼을 삭제하거나 변경할 수 없으며, 컬럼의 값을 수정하거나 삽입할 수도 없습니다. 데이터 행이 데이터베이스에 삽입되면 rowid는 행의 수명 주기 동안 고유합니다. 즉, 행이 행 마이그레이션을 수행하더라도 rowid는 변경되지 않습니다.
ROWID를 사용하는 이유
rowid는 테이블의 특정 행에 대한 가장 빠른 액세스 방법을 제공합니다. ROWID를 통해 해당 데이터 블록을 직접 찾은 다음 메모리로 읽을 수 있습니다. 인덱스를 생성하면 인덱스는 인덱스 컬럼의 값뿐만 아니라 인덱스 값에 해당하는 행의 ROWID도 저장하게 된다. 이렇게 인덱스를 통해 해당 행의 ROWID를 빠르게 찾은 후, ROWID를 통해 데이터를 빠르게 쿼리할 수 있습니다. 이것이 인덱스 쿼리를 사용할 때 더 빠른 이유입니다.
이전 버전의 ORACLE8에서는 ROWID가 FILE, BLOCK, ROW NUMBER로 구성되었습니다. Oracle8에서는 객체 개념이 확장되면서 ROWID가 OBJECT, FILE, BLOCK, ROW NUMBER로 구성됩니다. DBMS_ROWID를 사용하여 rowid를 위 부분으로 분해하거나 위 부분을 유효한 rowid로 결합할 수 있습니다.
Recursive SQL 개념 때때로 사용자가 발행한 SQL 문을 실행하기 위해 Oracle은 이러한 추가 문을 '재귀 호출' 또는 '재귀 SQL 문'이라고 부릅니다. 예를 들어 DDL 문이 실행되면 ORACLE은 사용자가 DDL 문을 성공적으로 실행할 수 있도록 데이터 사전 정보를 수정하기 위해 항상 일부 재귀 SQL 문을 암시적으로 실행합니다. 재귀 호출은 필요한 데이터 사전 정보가 공유 메모리에 없을 때 자주 발생합니다. 이러한 재귀 호출은 하드 디스크에서 메모리로 데이터 사전 정보를 읽습니다. 사용자는 이러한 재귀 SQL 문 실행에 신경 쓰지 않고 필요할 때 자동으로 이러한 문을 내부적으로 실행합니다. 물론 DML 문과 SELECT 모두 재귀 SQL을 유발할 수 있습니다. 간단히 말해서 트리거를 재귀 SQL로 생각할 수 있습니다.
행 소스
쿼리에 사용되는 이전 작업에서 반환된 한정 행 집합은 테이블의 모든 행 데이터 집합일 수도 있고 위의 두 행 데이터 집합일 수도 있습니다. 행 소스. 연결 작업(예: 조인 연결) 후에 얻은 행 데이터 모음입니다.
술부
쿼리의 WHERE 제약 조건
드라이빙 테이블
이 테이블을 외부 테이블(OUTER TABLE)이라고도 합니다. 이 개념은 중첩 및 HASH 조인에 사용됩니다. 행 원본이 더 많은 행 데이터를 반환하면 모든 후속 작업에 부정적인 영향을 미칩니다. 이는 구동 테이블로 변환되지만 실제로는 구동 행 소스로 더 정확하게 변환됩니다. 일반적으로 쿼리 제한을 적용한 후에는 행 소스가 적은 테이블이 구동 테이블로 반환됩니다. 따라서 큰 테이블의 WHERE 조건에 제한(예: 동등 제한)이 있는 경우 큰 테이블도 구동 테이블로 사용됩니다. 적절하므로 더 작은 테이블만 구동 테이블로 사용할 수 있는 것은 아닙니다. 쿼리 제약 조건을 적용한 후 더 적은 수의 행 소스를 반환하는 테이블이 구동 테이블로 사용된다는 것이 올바른 설명입니다. 실행 계획에서는 상위 행 소스여야 합니다. 구체적인 지침은 나중에 제공됩니다. 이후 설명에서는 이 테이블을 일반적으로 조인 작업의 행 소스 1이라고 합니다.
프로브 테이블(프로브 테이블)
이 테이블을 내부 테이블(INNER TABLE)이라고도 합니다. 드라이버 테이블에서 특정 데이터 행을 가져온 후 조인 조건을 충족하는 테이블의 행을 찾습니다. 따라서 테이블은 큰 테이블이어야 하며(실제로는 더 큰 행 소스를 반환하는 테이블이어야 함) 해당 열에 인덱스가 있어야 합니다. 이후 설명에서는 이 테이블을 일반적으로 조인 작업의 행 소스 2라고 합니다.
결합 인덱스(연결 인덱스)
emp(col1, col2, col3, ...)에 인덱스 idx_emp를 생성하는 것과 같이 여러 열로 구성된 인덱스를 사용하면 idx_emp 인덱스를 복합 인덱스라고 부릅니다. 결합된 인덱스에는 선행 열이라는 중요한 개념이 있습니다. 위의 예에서는 col1 열이 선행 열입니다. 쿼리를 만들 때 "where col1 = ?" 또는 "where col1 = ? 및 col2 = ?"를 사용할 수 있습니다. 이러한 제한은 인덱스를 사용하지만 "where col2 = ?"는 인덱스를 사용하지 않습니다. 따라서 선행 컬럼이 제한 사항에 포함된 경우에만 결합 인덱스가 제한 사항에 사용됩니다.
선택성:
열의 고유 키 수와 테이블의 행 수를 비교하여 열의 선택성을 결정합니다. 해당 컬럼의 "고유 키 수/테이블의 행 수" 비율이 1에 가까울수록 해당 컬럼의 선택도가 높고, 인덱스 생성에 더 적합한 컬럼이며, 인덱스의 선택도가 더 높다는 것을 의미합니다. 또한 더 높습니다. 선택 가능성이 높은 열을 쿼리하면 더 적은 양의 데이터가 반환되므로 인덱스 쿼리가 더 적합합니다.
이러한 배경 지식을 바탕으로 실행 계획을 소개하기 시작합니다. 명령문을 실행하기 위해 Oracle은 여러 단계를 구현해야 할 수도 있습니다. 이러한 각 단계는 데이터베이스에서 데이터 행을 물리적으로 검색하거나 명령문을 실행하는 사용자가 사용할 수 있도록 어떤 방식으로든 준비하는 것일 수 있습니다. Oracle이 명령문을 실행하기 위해 사용하는 이러한 단계의 조합을 실행 계획이라고 합니다. 실행 계획은 SQL 최적화에서 가장 복잡하고 중요한 부분입니다. ORACLE이 내부적으로 SQL 문을 실행하는 방법을 알아야만 최적화 프로그램이 선택한 실행 계획이 최적인지 여부를 알 수 있습니다. 재무제표가 재무 담당자에게 중요한 것처럼 DBA에게도 실행 계획이 중요합니다. 따라서 우리가 직면한 주요 문제는 실행 계획을 얻는 방법, 실행 계획을 분석하여 성능에 영향을 미치는 주요 문제를 찾는 방법입니다. 다음에서는 트리 실행 계획 분석부터 시작하여 실행 계획을 얻는 방법을 소개하고 실행 계획을 분석하는 방법을 소개합니다.
예:
이 예에서는 다음 SQL 문의 실행 계획을 보여줍니다.
SELECT ename, 직업, sal, dname
Emp, 부서에서
여기서 emp.deptno = derpt.deptno
그리고 존재하지 않음
(선택하다 *
살그레이드에서
losal과 hisal 사이에 emp.sal이 있는 경우 );
이 문은 급여가 권장 급여 범위에 속하지 않는 모든 직원의 이름, 직업, 급여 및 부서 이름을 쿼리합니다.
이 기사는 CSDN 블로그에서 가져온 것입니다. 재인쇄할 때 출처를 표시하십시오: http://blog.csdn.net/lcyhjx/archive/2009/12/20/5044672.aspx