[已解决问题] ROW_NUMBER() 分页的时候，好像没有利用非聚集索引
提问时间: 2008-06-22 10:20
悬赏分：10 浏览:245 次
通过执行计划分析来看，使用 ROW_NUMBER() 的时候，好像没有利用非聚集索引
with t_pager as (
select *,myIndex = ROW_NUMBER() OVER (ORDER BY Empcode ) FROM Employee
where EmpTypeID = 2
)
SELECT * from t_pager WHERE myIndex between 11 and 20;
Empcode ,EmpTypeID 这两个字段加不加非聚集索引，计划分析的结果都是一样的。只有按照主键排序，计划分析才会不一样。
分页结果倒是正确的。效率好像还很高。严重不解中。
问题补充：默认的情况，主键都是聚集索引呀。除非单独设置。
排序是非常咱用资源的呀，利用索引的话，就可以节省很多的资源，这个对于分页是很重要的！
聚集索引的话，正序和倒序执行计划都是一样的。不知道你有没有看过，我刚刚看过了，一样的。
=============
服了你了。感谢你来捧场。
EmplID就是主键，就是默认的。是聚集索引。
如果是其他的分页算法，那么就可以利用非聚集索引了。
最佳答案
1、ROW_NUMBER() 为什么要加载索引（管它是聚集还是非聚集）？排序操作而已。
2、主键 “绝对不等于” 聚集索引。
3、“只有按照主键排序，计划分析才会不一样”，说明你的主键完全是默认设置的。你要不试试(ORDER BY 你的主键 DESC)，然后再看看执行计划？
～～～～～～～～～～～～～～～～～～～～～～～～～～
分析：这里需要了解的知识点主要在聚集索引和非聚集索引的存储方式上，然后再加上“排序操作究竟是在干什么”，然后你就能非常清楚这个问题的“为什么”了。
提问者对于答案的评价：这个，到底结贴了吗？晕了。
2008/6/22 14:42:49
回答者：电机拖动
提问者对于答案的评价：这个，到底结贴了吗？晕了。
其它回答(2)
|
sql按照那一个索引进行查询是查询优化器做的，除非你在sql语句中指定根据那个索引来查（参考：http://www.google.cn/search?hl=zh-CN&q=%E6%8C%87%E5%AE%9A%E7%B4%A2%E5%BC%95%E6%9F%A5%E8%AF%A2&meta=&aq=f）。 但是一般不推荐指定索引。 |
评论
|
2个月前 电机拖动 : 哦，不好意思，我没说清楚，我的意思是：DESC时的分页结果不同，而计划几乎一样（成本一样）。这个效果说明了聚集索引与非聚集索引的区别。 排序的确占资源，不过，当排序的集合比较小时，自然就不占资源了 另外，针对你的问题，非聚集索引的存储机制就决定了它不会在排序时一定起作用。你这个查询非常简单，因此，只要你的Empcode的排序与聚集索引一致（不是DESC或ASC那么简单，而逻辑上）即可实现取消排序的效果。如果是较为复杂的，就算是有聚集索引都不一定能取消排序操作。 此外，还要看你的SORT操作到底成本是怎么样的，如果比较低，比如1%，那么需要优先优化的对象就不应该是它了 另外，根据你的表名，我估计你这个表的主键应该是EmployeeID，你的主键再使用默认设置，白白的浪费了聚集索引这么紧俏的资源…… |