查询效率调优

用户报说统计查询慢，在页面尝试了下，统计两个月的数据大约需要5秒，把那段执行的SQL，直接通过toad连接到数据库中尝试，1秒不到。

初始以为是代码问题或者是jdbc驱动等问题，后来尝试应用连接不同数据库，结果如下

开发数据库 数据总数2181377条，首次1100ms，后面平均查询速度719ms

测试数据库 数据总数2187115条，首次10422ms，后面平均查询速度5300ms

生产数据库 数据总数2637793条，首次14563ms，后面平均查询速度6500ms

由于被查询的表的数据量在三个库中属于一个数量级，而且均为oracle11g数据库，因此我们曾怀疑是网络通信速度问题，直到网上搜到《Troubleshooting Oracle Performance 》这本书

里面有写到这么几句：

总的来讲，为了提高执查询优化器生成高效的执行计划的可能性，最好不要使用绑定变量。绑定变量有时候可能有用。遗憾的是，生成的执行计划是否高效只能看运气如何。唯一的例外是，Oracle数据库11g中的新的扩展的游标共享会自动识别这个问题。

使用任何特性都需要权衡利弊得失。有些情况下，这是比较容易决定的。例如，在不涉及到Where从句（如普通的插入语句）的时候，就没理由不使用绑定变量。另一方面，在柱状图信息对查询优化器有很大影响的情况下，最好不要使用绑定变量。否则，可能会在进行绑定变量窥视的时候遇到较大负面风险。不过，还有以下两个关键案例可供参考：

• SQL语句处理少量数据：每逢被处理的数据量很少的时候，解析时间有可能会接近甚至高于执行时间。在这种情况下，使用绑定变量就经常是一种较优选择。特别是在SQL语句将会频繁执行的情况下。数据资料系统（data entry system，常常也称之为OLTP系统）是典型的使用这种SQL语句的系统。
• SQL语句处理大量数据：在大量数据被处理的情况下，解析时间常常比执行时间要少好几个数量级。在这种情况下，使用绑定变量对于总的响应时间（response time）几乎没有影响，但是它也会提高查询优化器生成低效的执行计划的风险。因此不要使用绑定变量。批量任务处理（batch job）、报表生成或者运用OLAP工具的数据仓库（data warehouse）环境是使用这种SQL的典型场景。

虽然文章中说是Oracle数据库11g能自动识别这个问题，但我们总结下来，应该就是这个问题，我们的数据库自动生成的执行计划有问题，因此我们改了我们的查询代码，由原来的游标方式改为直接把变量拼到sql语句中，然后执行测试，果然，测试系统和正式系统的查询时间大幅下降，甚至正式生产数据库执行的更快，这可能归功于正式数据库服务器性能更好。