SQL Server 优化--合理使用聚集索引

今天在监控数据库时，发现一个语句的执行时间比较长，IO次数也比较多。语句如下：

select * from Docbase this_ where

id in ( select objid from Categorylink categorylink where

categorylink.objtype='Docbase' and (categorylink.categoryid =

'4028827015a82d020115d07b6b604689')) and pid is null and isdelete=0 and

exists(select 'X' from Permissiondetail p where p.objid=this_.id and

p.objtable='docbase'and p.userid in('','ISALLUSER','402882ed0eb78aae010ec124f7fe5c87',

'402881a10d33db44010d3402fc2b00c3') and 10 between p.minseclevel and p.maxseclevel and p.opttype > 2 ) and not exists (select 'X' from Delobj del where del.objid=this_.id and del.objtable='Docbase')
由于表Permissiondetail表数据有很多，大约有几百万条数据，先前建立一个索引来达到索引覆盖，避免表扫描。

CREATE INDEX [IX_PERMISSIONDETAIL_mu] ON [dbo].[permissiondetail]

(

[objid] ASC,[objtable]ASC,[userid] ASC,[minseclevel] ASC,[maxseclevel] ASC,[opttype] ASC

)

执行结果如下：

(495 行受影响)

表 'delobj'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'docbase'。扫描计数 1，逻辑读取 659 次，物理读取 0 次，预读 0 次，lob 逻辑读取 85 次，lob 物理读取 0 次，lob 预读 0 次。

表 'categorylink'。扫描计数 3，逻辑读取 36 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'Permissiondetailworkflowbase'。扫描计数 1，逻辑读取 30690 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

后来发现这样的优化效果也是不明细，因为这里运行的速度也不是很快，因为数据库是Index scan,他会对索引的全部数据进行扫描。一旦数据量大，也很慢，而且这个索引的长度太长了，影响DML语句。后来通过分析表的数据分布。和userid的数据情况，在userid里建立一个聚集索引，效率会大于索引覆盖。

CREATE clustered INDEX [IX_PERMISSIONDETAIL_userid] ON [dbo].[permissiondetail] ( [userid] ASC)
执行语句结果：

(495 行受影响)

表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'Permissiondetail'。扫描计数 1988，逻辑读取 10106 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'docbase'。扫描计数 1，逻辑读取 659 次，物理读取 0 次，预读 0 次，lob 逻辑读取 87 次，lob 物理读取 0 次，lob 预读 0 次。

表 'categorylink'。扫描计数 1，逻辑读取 12 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'delobj'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
结果：是IO次数比先前提高了3倍，而且DML的影响是比较少的。

总结：

这个案例有个特殊性，就是对Permissiondetail大表会有查询很多的数据，这时如果不能达到索引覆盖，执行的时间比较长，但是这样的做饭牺牲了很多其他的性能：插入，更新和删除数据，不是最优的。我们更改了索引，将userid改成聚集索引，一样达到了提高效率的方法，同时也提高了DML的效率。

有时：聚集索引效率>索引覆盖，具体要看情况，这只是其中的一个例子。