我有以下人为的表
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
所以我想要所有来自 car 的汽车都有 carmake.code = 123
如果我这样做......我会得到下面的详细计划
select id FROM car c JOIN carmake m ON c.make = m.make where m.code = 123
请注意，它的表扫描大表 - 啊！
如果我执行其中任何一项...计划显示它使用 i0 索引
select id from car where code ='make1' OR code ='make2'
select id from car where code in('make1','make2')
一旦您加入 make 表以根据代码派生 make，查询计划就会开始创建重新格式化的工作表，然后对大表进行表扫描。
我不知道为什么。sybase 文档指出，当要连接的表之间没有合适的键时，会发生重新格式化。在这种情况下，两个表都有 make char(10) 索引。我还尝试在代码上添加索引，以便不扫描表，但这仍然会导致初始重新格式化。我怀疑重新格式化会导致无法使用汽车索引 - 可能是因为类型冲突和隐式转换？但是为什么首先会发生格式化呢？
重新格式化然后进行表扫描计划：-
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