刚刚做完的特性提出了性能问题，在执行阈值数据导出时效率低下，300行数据耗时10s以上，随着数据规模的增大，效率已经低下到无法忍受了。
介绍一下需求背景:
1. 从数据库中取出数据
数据量较大，但数据库并非问题瓶颈
2. 去掉无效数据并返回
需要通过两次嵌套循环格式化数据
优化措施：
a. 去掉重复数据库访问
在逻辑中存在有根据条件查询表名称的操作，当时误放置到了循环体中，起始查询结果与循环体无关，将其移除，减少50%的数据库访问次数。
b. 优化查询逻辑
原有的逻辑是根据不同的指标进行一次访问，因此访问次数为N，但经过对业务逻辑的梳理，发现不同指标的查询条件中对于时间的选取是一致的，因此将单次查询组合结果改为了通过sql的in语句执行，最后优化到1次
c. 对于string组合的处理
将频繁的string+改为通过StringBuffer处理，性能有所提升，但不明显。
d. 去掉无用步骤
在数据库优化结束之后，发现性能依然低下，原因为后数据处理消耗过大，原后数据处理只是为了将查询数据整理使用，经分析调用获知，使用方式为getKey，因此不再进行数据剔重。
后经测试，阈值不再是导出瓶颈，优化完成。
总结：
“过早优化是万恶之源”。在没有目标时，最好什么都别做。这时测试环境不具备，依赖条件处于变化之中，用户没有反馈，这时的优化更有可能导致不必要的异常。
对于影响性能的基本编码习惯要注意，比如耗时操作不要放到循环体，使用StringBuffer代替String执行拼接等，这些操作有助于提升性能，但往往不是最根本的。
复杂的业务逻辑是影响性能最主要也是最难以优化的内容，在逻辑上提升，往往能够较快的达到要求。