现象

公司的一个APP点击某些页面非常缓慢，有些等待1分钟，出现大部分用户不想使用的情况。

目标

要在3天内完成优化，越快越好。

解决

索引

1. 分析：某些跨表查询没有建立索引，虽然单表只有30万数据，但是一关联查询，特别是4、5张表关联时极其缓慢。
2. 解决方法：建立索引即可。

缓存

因为数据都从oracle数据库读取，我们首先想到的就是使用缓存代替。把全部配置表的数据放到Ehcache缓存中，不直接从oracle读取，提高效率。

• 为何选用Ehcache？请阅读《缓存选型-Ehcache、memcached、Redis》
• 如何使用Ehcache？请阅读《Ehcache的一个完整例子》

分页

1. 发现有一个页面查询需要5秒，比较慢。发现其实结果集是379条详细记录，作了379次循环全部查出，一次显示。而实际上用户不需要一次观看379条记录，完全可以采用分页。APP页面每页只显示了10条，翻页时再查询下10条。这样立马1秒内能响应。
2. 还发现有几个页面，查询条件里的时间默认是为空的，那样子用户点击查询默认就是查询全部数据，虽然这些页面作了分页，但是数据需要排序，把时间最靠前的先显示，这种情况下如果数据量上了30万以上，无论索引如何优化都是无法做到1秒内完成查询的。而实际上用户并不需要查询所有的数据，只需要把查询时间默认设置为查询最近2天，修改后1秒内完成响应。

集群

目前APP、后端服务都只部署在一个weblogic上，考虑到以后业务发展，用户数突增，需要考虑weblogic集群来进行负载均衡。目前主机有256G内存，足够运行，但在近期需完成集群优化防止性能下降再次造成用户不满。

总结

上述四种优化后，APP基本快速响应，用户使用还算比较满意，但其实，最关键的还是索引和分页的优化。

• 缓存的优化不是没有作用，而是太小，oracle的查询其实已足够快速。我做了一个实验，结论是oracle查询一次16毫秒，第二次同样的SQL语句是0毫秒，而缓存也是0毫秒，所以非特殊情况下，基本没有任何优化效果。
• 集群只是一个预防的措施，因此暂时来看作用不是很突出。

ouyida3的csdn博客
2015.4.10