mssql数据库分页查询效率的一次体会
这几天在一个项目，合同管理系统(是对老系统的升级和改造，老系统是VS2008做的)，由于数据库的表是项目组根据老系统的数据库建的，所以在查询的适合我就需要自己创建视图来完成多表的查询，起初我是读取项目组成员建好的视图，里面有7张表，其中还包含视图，由于视图中join视图是不支持索引的，所以在查询第一页的时候(每一页20条数据，总共数据量是10W条左右)，耗时800毫秒,但是
当row_number达到上千的时候，基本查询要6秒以上，每点击下一页，耗时会增加十几毫秒，到40000条也就是中间的时候，基本是超时了，在数据库执行也要3分钟多，这还没有加上查询条件和join Dictionary表去value的值(数据查询出来的很多字段都是key 需要自己去到Dictionary表取value)
对这类情况我是头一次碰到，通过分析和了解发现row_number越往后越慢是普遍存在的现象,
第一种解决方案是 项目组给的建议是写存储过程，写了之后，效果一样不理想，
第二个解决方案是 改变分页方法，用正反分页的方式来完成查询功能， 这样导致的结果是两头比较快，中间最慢，通过编写存储过程的测试后，发现中间部分最慢的地方需要3-7秒， 这个也不理想
第三个解决方案是我自己想出来的， 就是在不影响业务的情况下，把视图中的表减少，通过分析所以的查询条件全部在两张表里面，那我就把这两张表建了一个视图，然后在查询的时候也做了一些小的变动，就是再通过排序和条件筛选后，先取出1页的数据，然后再拿这1页的数据去join其他表和视图，取出对应value值， 这样测试后得到的结果是 所有的页都可以保证在1秒内完成查询，不会出现每点击下一页偏移几十毫秒的情况(没有用存储过程，是通过linq的方式完成的查询)
对于linq动态拼接条件有两种方式，我是参考了 http://blogs.msdn.com/b/meek/archive/2008/05/02/linq-to-entities-combining-predicates.aspx 这里面的方式编写的，
好了今天就到这里了，明天继续，有更好的分页方式希望能分享一下，写的不好请大牛们手下留情...
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
