前言
公司很多应用都是与报表有关的，但是很多报表每次生成都需要花很多时间。正好前段时间不是很忙，就把优化提上日程。郁闷的是很多报表运行时间都超过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 '%…..'，因为如果这列有索引的话是没效果的。
