前言

    公司很多应用都是与报表有关的，但是很多报表每次生成都需要花很多时间。正好前段时间不是很忙，就把优化提上日程。郁闷的是很多报表运行时间都超过1分钟，长点儿的能达到30分钟以上。额滴个神呀，这还得了？对我们来说超过1分钟都难以忍受了，不过BU觉得几分钟还是可以接受的。最终盯住的是那些超过10分钟的报表。

    报表运行的信息都在ReportServer数据库有记录（当然报表还没运行完毕就把页面关了的就没办法了），查出来后，剩下的就是优化对应的存储过程了。当然也有的报表速度慢是因为报表处理数据的时候逻辑有问题。

正文

    下面就在优化的过程中遇到的问题做下总结：

1. 查询中剔除冗余列、表

查询的时候，一些不需要的列可以去掉，不需要的表就更没必要要了。一方面减少表扫描时的输出列表，另一方面减小数据传输。

2. 尽量不使用动态查询

关于这点，可以先了解一下执行计划和缓存（具体可查阅帮助文档）。在SQL Server可以处理一个T-SQL批处理之前，它需要创建一个执行计划。为了使SQL Server创建一个执行计划，它必须首先消耗一些宝贵的资源，比如CPU来编译一个T-SQL批处理。当一个计划编译后，它被缓存起来，因此在你的应用程序不止一次地调用相同的T-SQL语句时它可以被重用。所以，尽量不使用动态查询。

3. 临时表和表变量的选择

临时表存储在tempdb数据库中，而表变量在内存中。包含表变量 查询不会生成并行查询执行计划。特大型表变量或者复杂查询中的表变量可能会影响到性能。在这种情况下，请考虑改用临时表。所以表变量和临时表的选择要视情况而定。

4. JOIN

可考虑将子查询转换为JOIN联结查询。表应按结果记录数从大到小的顺序从左到右来排列，因为表间连接时，最右边的表会被放到嵌套循环的最外层,最外层的循环次数越少，效率越高。不明白这句在搞什么飞机。

5. 查询中尽量少使用函数结果当作列

查询中尽量少使用SELECT fn,fn,fn… ，在Management Studio里看着结果集一条一条的出来的时候，很有种砸电脑的冲动。最终改成用临时表存储结果集，然后用UPDATE修改列。

6. 索引的使用

使用索引的时候应该要慎重，索引列的数据类型、列的长度、表数据量、表索引的个数都对性能有影响。有时候对临时表建索引也很有效果。

7. 需要生成交叉表格报表以汇总数据时，用PIVOT代替一系列复杂的SELECT...CASE语句。

PIVOT关键字是SQL2005时新增的，用来做交叉表还是很不错的。

8. WHERE子句中条件的顺序对性能没有影响

虽然SQL语法分析是从右到左，但是WHERE条件的顺序跟查询无关。

9. LIKE操作符

最讨厌的就是LIKE '%…..'，因为如果这列有索引的话是没效果的。