MicroHelper.Net

在优化一段sql的时遇到性能问题，sql结构如下

create table #report (...)

insert #report (...)
select ..., fnGetDate(OrderDate) as OrderDate
from ...
where ...

数据量非常小，执行时却发现执行非常慢，大大超过预期。查看执行计划发现table spool/eager spool的时间占了99%，后来发现，如果去掉insert,只执行select,速度相差20倍，就认为这是问题的根源。

想了很多办法来优化速度，比如用表变量替换临时表，直接insert，加top 10000000，用实际的表换掉临时表等等，不见效果。后来逐个字段检查，发现加上OrderDate，性能马上就降下来了。

fnGetDate是一个格式化时间的函数（虽然一般来说格式化的工作不应该在sql中处理，但是这个例子是需要的），目的是把把时间格式化成2004-Nov-01这样格式，后来确定可以应用2004-11-01这种格式，但是有的地方没有改过来，比如这里。

问题找到，把fnGetDate换成convert，速度马上提高20倍。但是问题还不算解决，其他的很多地方都用到了fnGetDate,但是速度没有太大影响,应该还有其他的原因。

后来发现一个现象，加top 10000000与不加两种对比，速度相差7倍，应该还是查询写的有问题，有的地方没有用到索引。经过一番调整后系统恢复正常运行。这时候再把convert换回fnGetDate速度没有太大的变化。

sql server的执行计划虽然会告诉我们我们一个sql执行的详细情况，但是只看表面现象有时候容易差生误导，比如上面的例子，一般来说sql的性能问题大部分由于查询设计的不合理和Index不合理以及资源锁定造成的，发现问题应该首先分析这几方面。

函数确实对性能是有影响的，但是加了函数以后对sql执行造成这么大的影响还是第一次碰到。

打印 | 张贴于 2004-11-16 16:12:00 | Tag:暂无标签