大数据量查询的优化（转载）

http://visualcatsharp.iteye.com/blog/283705

感谢visualcatsharp，学习中

某个库中有一个论坛主帖表，每天增加数千的数据，现在整个表的数据量已经是百万级。由于论坛不断升级，增加了N个字段，为了实现良好的扩展性，将某些字段移到了一个子表中，而子表中的某个字段又是外键关联另一个表。没有添加任何非聚集索引。
    当使用top查询N条数据的时候，就算三个表之间进行关联查询，由于服务器性能出众和SQL Server 2005对大数据量的处理能力的提升，查询时间都能在个位数下；但当需要进行分页查询的时候（使用select …where id not in (selet …) 的方式），竟然数十秒甚至几分钟都完成不了查询。
    分析一下有什么地方可以优化的：
1、 以前是两个表，一个表是百万级数据，另一个表只有几条固定的数据；现在是两个百万级的数据表，再加上一个只有几条固定数据的表，两个百万级别的表进行关联查询，性能肯定有影响。
2、 无论是两个表还是三个表，表与表之间的关联是写在视图里的，是否可以创建索引视图进行优化？
3、 查询的时候大多数会加入两个以上的字段进行条件查询，亦会加入一到两个的字段进行排序，在这些字段上创建单独或复合的非聚集索引应该可以得到较大的性能提升。
4、 查询语句是否导致了全表扫描？
结果：
1、 将作为条件查询的字段放在主表里，子表只放一些基本上不会作为条件查询的字段，从而可以使三个表关联查询的情况只发生于查询单条数据。
2、 这个查询所使用的视图并没有指定查询条件，因此索引视图无用武之地
3、 因为由于需求的原因，经常使用的数据占了表数据量的90%左右，经测试，对这些字段添加非聚集索引对性能提升影响不大；而对两个常用的排序字段（创建时间，最后更新时间）分别添加单独的索引，并对这两个字段添加复合索引，对性能的提高的影响是非常大的。
4、 经过分析，这个查询中不存在全表扫描。
        经过以上优化，直接在数据库执行对论坛帖子查询的存储过程（整个系统对数据库的操作大部分都是使用存储过程），无论是查询top N条数据，还是进行每页50-200条的分页查询，经肉眼观察都在1秒内完成。至于具体详细的查询时间，并没有用SQL Profiler监测。优化后，就算执行千万级的查询，查询也不会太费劲。