今天在工作中遇到一个问题，本来已经通过测试部门测试的程序，部署上线以后不能正常运行，检查后发现是因为线上数据量大导致的，最后通过在查询中增加对索引列的处理，以及缩小查询范围解决。在网上找到一篇文章，里面详细讲了查询优化的思路，感觉不错。

01：找专业的数据库管理员，给了我们一些建议系统底层优化的建议，对我们没实质性的进展，失败。

02：只能硬着头皮与同事们一起深入研究，发现SQL语句也很复杂，并没有想象的那么简单。

03：把比较复杂的SQL语句先分解成若干个简单的SQL语句，运行、失望，性能影响不大，失败。

05：里面有些多余的字段被SELECT出来的字段，去掉了，没有明显的进展，影响不大，失败。

06：SELECT 出来的东西，再进行了SUM操作，感觉内存里的处理数据过大，先进行SUM，再进行SELECT，没有明显的进展，影响不大，失败。

07：把表拆开成若干个表，没有明显的进展，影响不大，失败。

08：修改数据类型，把数值类型的长度、精度在变小点儿，影响不大，失败。

09：数值类型比较，例如日期类型的比较，不要转成字符再比较，人家已经这么做了，没这方面的缺陷。

11：查询条件的先后顺序调整，影响不大，失败。

12：将过滤条件放到子语句里，选出来的数据尽量小一些，影响不大，失败。

13：再看看索引，以前的开发人员索引设置得也比较合理，而且他们告诉我们，他们做测试优化索引，耗时会更多，去掉索引反而还会好一些。

14：经过这8个步骤，我是有些失望了、心情沉重，但是我不能把这个表现出现，还是继续表现得很自信，不管遇到什么困难，都需要给自己打气、给自己信心，男人要坚强、只能靠自己了。

15：接下来足足想了一晚上，问题会出在哪里？数据库的极限能力是多少？找谁咨询？2000W条数据不应该是Oracle的性能瓶颈呀，问题应该是我们身上。

16：继续坚信问题应该是在设置索引上，继续把重点突破口放在深入索引设置上，按不同的组合、不同的索引方式进行优化。

17：索引优化后，奇迹出现了，性能提高了100倍。