【性能优化】不调整功能代码的Web分页优化

　　今天在公司论坛上看到一位同事发表的一篇有关Web分页方式的帖子，让我想起了2010年时处理过的一个优化分页的解决方案，记录下来等老了再回过头来看看，哈哈：

介绍

　　1、页面需要显示的一些业务数据，这些数据信息从多个表中进行组合查出的，而数据量以百万计。

　　2、我们的框架是Spring + Hibernate + JSF，然后在这三大核心技术的基础上做了更高的抽象和封装（当然对JDBC SQL的封装是必须的，而在遇到问题调整时，也突显了它的优势），以降低开发成本，提升开发效率（保守估计我们的开发效率提升了30%）。

处理里程

　　1、架构最先处理方式

　　　　所有的分页是由框架进行自动处理的（前后台），采用的机制是先查出总页数，然后在根据分页逻辑和分页信息进行查询当前页数据。

　　2、初测阶段，初现性能问题

　　　　这种分页机制在以十万计的数据量下，执行简单的SQL查询时，运行效率还是可以被接受的，但如果是复杂SQL或数据量更大时，就出现了性能问题，于是我们加入了关键字段索引（这属于SQL的最简单优化方式）。

　　3、整合测试阶段，再现性能问题

　　　　这次我们测试到一支功能，初次查询需要30秒，后平均为23秒左右能查出结果。经过分析我们发现这是一支类似报表的功能，页面所需要呈现的数据是由多个视图JOIN连接得出的（由于某些原因，我们只能通过视图提取这些数据），而每个视图又是一组非常复杂的SQL组成。经过组内讨论我们决定在分页处理上“做手脚”，由于对数据的时时性要求不高，我们决定将原来的两次查询（一次查询总记录数，一次查询当前业务数据）缩减为一次查询。这样只有在初次操作（进入功能页面时，执行的初次查询操作）时查询总页数，后面的查询将记录总条数，只查询所需业务数据。这种方案在第一次执行时，效率没有效果，但在后面的操作中（点击页码查询）却显示出了它的威力，在原先性能上提升了52%。虽然二次查询（点击页码的查询）性能方面有了有效提升，但初次查询依然存在问题，后来利用ORACLE的方言SQL，又使初次查询性能提升了34%。

　　优化方案已经解决，接下来就是如何调整分页架构。经统计我们发现，有此类问题的功能只有很少的几支，所以我们决定在原分页基类上再抽取一支特殊的子类，凡是类似问题的功能，都继承自此类，这样性能得到的优化，而功能代码也几乎无需调整。

　　最终我们的目的最终达到了。