Equi Join의 특별한 경우

Question

나는 equi join의 특별한 형태를 사용하는이 특별한 스크립트를 보았습니다.

SELECT * 
FROM 
per_assignments a, per_assigment_types b 
WHERE 
a.assignment_status_type_id + 0 = b.assignment_status_type_id 

동일 결합에 0이 추가되는 이유는 무엇입니까? 색인 검색을 피하는 것과 관련이 있다는 것을 알게되었지만, 여전히 어떤 사람은 색인 검색을 완전히 설명 할 수 있습니다. 미리 감사드립니다

편집 :

그것은 테이블/열 선언과 관련된 일이 아니다. 내가 아는 한 SQL 튜닝과 관련이 있습니다.

1. 이 작은 테이블에 사용됩니다 : -

   이것은 내가 찾은 것입니다.

2. 인덱스 검색을 정상적으로 수행하는 대신 전체 테이블을 한 번에 검색합니다.

그러나 정상적인 동등 조인과의 차이점을 정확히 알지 못하며, 색인 생성이 성능에 어떤 영향을 미치는지에 대해서도 알지 못합니다.

특정 상황에서 설명 할 수 있고 내 발견이 잘못 되었다면 알려주는 것이 도움이 될 것입니다. 같은 :-)에 대한 귀하의 시간과 노력을 감사합니다

열 설명 : 두 테이블

할당 상태 유형 아이디의 인덱스 사용을 살해 번호 (9)

Answer 1

이유로 선언 작은 테이블은 성능입니다. 인덱스를 사용하여 조인을 수행하면 데이터를 읽는 데 두 개의 디스크 I/O가 필요합니다. 하나는 인덱스를 읽고, 다른 하나는 전체 테이블에서 데이터를 읽는 것입니다. 작은 테이블을 사용하면 두 번째 디스크 I/O를 수행하는 것보다 전체 테이블을 읽고 전체 테이블 스캔을 수행하는 것이 더 빠를 수 있습니다.

이것은 일반적인 일반화이며 데이터베이스 에서조차 달라질 수 있습니다. 이론적으로 SQL Optimizer는이 조건을 인식하고 힌트가없는 경우에도 인덱스 조회를 통해 전체 테이블 스캔을 사용할만큼 똑똑해야합니다. 또한 하나 또는 두 테이블에 데이터를 추가하면 전체 테이블 스캔에서 인덱스 찾아보기로 더 빠른 성능을 이동시킬 수도 있습니다. 것이다 이러한 쿼리 조정에 대한 내가 가진

질문 : 포함한 테이블의 정확한 정의는 무엇

1. , 어떻게 전체 평균 VARCHAR 컬럼 (있는 경우)입니까?
2. 각 테이블에 몇 개의 행이 있습니까?
3. 하루에 각 테이블에 몇 개의 행이 추가됩니까?
4. 이 쿼리는 얼마나 자주 실행됩니까?
5. 누가 어느 옵션이 더 빠르게 실행되는지 쿼리 한 사람이 있습니까?

이 쿼리는 이전 버전의 데이터베이스 또는 단순한 영리한 성능 향상 기능으로 작성되었거나 쿼리 최적화 프로그램이 더 좋거나 더 좋은 작업을 수행 할 수 있다는 것을 깨닫지 못한 채 똑똑한 해킹으로 작성되었습니다.