delete from #employees从结果来看该存储过程其实就是执行了两条动态SQL，分别存在@SQL1和SQL2。我稍微修改了一下存储过程，加入了一些调试信息，打开统计器。
SET STATISTICS IO on;
SET STATISTICS TIME on; 执行存储过程，这里由于信息量比较大，我就不贴了，上一张图吧。
可见@SQL1的语句耗时并不多，@SQL2资源占用是非常厉害的。其中 Log 表扫描530次，这个表的数据量有257417条，说大不大，说小也不小了，而且还得扫描530次，唉，啥也不说了，而shouwen这张表就小很多也有25000+条记录。
我将@SQL2的语句整理出来，去掉那个讨厌的 insert into #employees。
select distinct s.parentId,s.pkId,1,s.title,s.comeOrg,s.fileDate,
s.fileName,s.filePath,1,l.optionstatus,s.remark3,urgencyLevel
from shouwen as s,
log as l
where
(s.fileSerialNumber like '%%' or s.title like '%%'
or s.keywords like '%%' or s.fileZi like '%%')
and s.status<>'4'
and s.pkid in
(select distinct(mid) from log where uid='glzyf' and typeid='shouwen')
and l.mid=s.pkid and uid='glzyf' and typeid='shouwen'
s.fileName,s.filePath,1,l.optionstatus,s.remark3,urgencyLevel
from shouwen as s,
log as l
where
(s.fileSerialNumber like '%%' or s.title like '%%'
or s.keywords like '%%' or s.fileZi like '%%')
and s.status<>'4'
and s.pkid in
(select distinct(mid) from log where uid='glzyf' and typeid='shouwen')
and l.mid=s.pkid and uid='glzyf' and typeid='shouwen'
order by s.fileDate desc 看看这个select 语句的执行计划啦。
以下才是重点，两个在Log表上面的“聚集索引扫描”：
无论哪个RDBMS的语句调优，绝大部分的情况下都是将执行计划中的“扫描”转变为“查找”。下一篇讲解如何将“扫描”变为“查找”。
