一个好的建议是，直接使用Oracle的统计表。我们可以清除SQL语句的缓冲池，在大连读屏软件开发执行过程中，观察缓冲池中SQL语句的执行状况，例如，执行次数、平均执行时间等。我们选取了那些Top SQL，对它们的执行计划进行了分析。

通过参阅相关资料和多次尝试，我们得到了一些经验知识：

     提升大连读屏软件开发SQL语句的执行效率本质上就是降低磁盘的访问次数，通常来说，可以通过建立索引和避免对大数据量的表进行全表扫描来实现；

索引稠密度并不能完全说明建立索引的合理性，还需要考虑数据分布，因此，索引应该尽量建在取值比较均匀的字段上。

     这些经验知识帮助我们明确了SQL语句的优化方向，同时也取得了很好的效果。我们甚至利用Oracle的特性来建立或屏蔽动态索引以及干涉SQL语句的执行路径。总之，目标只有一个——降低磁盘的访问次数。

在对缓冲池的观察中，我们还发现很多相似的大连读屏软件开发语句大量出现，这显然是没有使用绑定变量的缘故。在单用户下，这种做法导致的性能问题可能还不明显，但是在多用户并发的情况下（换句话说，在数据库访问极其频繁的情况下），会产生性能问题。这是因为，缓冲池是有一定容量限制的，当不断有新的SQL语句进入时，原先的SQL语句会被移除，这导致了SQL语句的硬解析。硬解析会使优化器重新创建解析树和生成执行计划，而这两个动作都是代价昂贵的，会影响SQL语句的执行性能。

     致远服软认为：http://www.soft8.com.cn/至此，对于SQL语句执行性能的问题，我们已经有了比较明确的解决方案。事实上，在以上提到的性能问题中，哪一点是软件设计和实现中无法避免的呢？没有。

我们把视线转向单个事务中的数据库访问次数。令人震惊的是，在一个事务中，竟然有几千次的数据库访问。每一次数据库访问，都需要客户端和服务器端的交互。这种交互会在网络上传递“相当可观”的字节数，更不要说CPU和内存上的消耗。

     我们对这个现象进行了分析，很快发现以下的问题。首先，系统中存在JDBC和Hibernate混用的情况。这导致了Hibernate大量的flush动作，flush会产生数据库的操作。这种做法让人厌恶。

这是软件设计和实现中无法避免的吗？不。其次，很多方法使用ID作为参数，每一次调用都要通过ID来构建数据对象，这导致了大量的数据库访问。这是软件设计和实现中无法避免的吗？不。

     最后，在循环中通过JDBC来访问数据库，如果循环次数很多，数据库访问次数会让人发疯。

这是安全漏洞软件测试和实现中无法避免的吗？

     我们尝试使用减少flush次数、传递对象、循环体外准备数据等方式来解决上面的问题。尽管取得了一定的效果，但感觉很差。如此大规模的程序，其结构仿佛来自本能，而不是来自良好的规划。