0
은 내가 carmake.code이 차에서재구성을 위해 작성된 Sybase 작업 테이블 - 이유가 무엇입니까? 내가 이렇게하면
car (id char(8) NOT NULL, make char(10) NOT NULL)
with NONCLUSTERED INDEX i0 ON car(make)
~80k rows of which ~2k are makes with code I need
carmake (make char(10) NOT NULL, code int NOT NULL)
with NONCLUSTERED INDEX i1 ON carmake(make)
~2k rows of which 2 have the code I want
그래서 나는 모든 차량을 원하는 다음과 같은 인위적인 표 = 123
... 난
아래의 세부 계획을 얻을 수있다큰 테이블을 스캔한다는 점에 유의하십시오. 나는이 중 하나를 수행 할 경우
... 계획은 즉시 코드, 쿼리 계획에 따라 차종을 유도 할 수있는 메이크업 테이블에 조인으로 I0 지수
select id from car where code ='make1' OR code ='make2'
select id from car where code in('make1','make2')
를 사용하는 것을 보여줍니다 다시 포맷 된 작업 테이블을 만들기 시작한 후 테이블이 큰 테이블을 스캔합니다.
이유를 알 수 없습니다. sybase 문서에는 결합 할 테이블 사이에 적절한 키가 없을 때 재 형식화가 발생한다고 나와 있습니다. 이 경우 두 테이블 모두 char (10) 인덱스를 만듭니다. 또한 make 코드가 테이블을 스캔하지 않도록 코드에 인덱스를 추가하려고 시도했지만 여전히 초기 재 포맷이 발생합니다. 재 형식화가 자동차 색인을 사용할 수 없음을 의심합니다. 아마도 유형 충돌과 암묵적 전환 때문일 수 있습니다. 그런데 서식이 처음부터 왜 발생합니까? 다음 테이블 스캔을 포맷에
계획 : -
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 3 worker processes.
STEP 1
The type of query is INSERT.
The update mode is direct.
Executed by coordinating process.
Worktable1 created for REFORMATTING.
FROM TABLE
make
m
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.
STEP 2
The type of query is SELECT.
Executed in parallel by coordinating process and 3 worker processes.
FROM TABLE
car
c
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Executed in parallel with a 3-way hash scan.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
FROM TABLE
Worktable1.
Nested iteration.
Using Clustered Index.
Forward scan.
Positioning by key.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
Parallel network buffer merge.
The sort for Worktable1 is done in Serial