一次奇葩的优化
现场同事打电话，说是有一条sql很慢，需要跑30多秒，需要优化一下。
系统是Windows server 2008 r2，数据库是oracle
1，远程过去，看了一下这个sql，就是select 列名 from 表 where 列=' '的一个sql。这是最简单的一个sql了。执行了一下确实花费了有30多秒。
2，查看表dba_ind_columns，发现这个where列上是存在索引的。
3，使用explain plan for select ... ; select * from table(dbms_xplan.display)查看执行计划，发现确实走了全表扫描。
4，查看表的行数，和索引列的唯一值的行数，发现两个值是一样的（200多万），也说明了这个索引列的选择性很好。
5，后来想是否因为统计信息的原因造成的，发现刚收集统计信息一个月，讲道理一个月统计信息不会有太大的变化。有可能这一个月数据暴增，问了现场的同事数据增长的情况，回答说是正常增长。为了确保万一，收集了这张表的统计信息。然后看执行计划发现还是走的全表扫描。无奈
6，后来select 出来这张表的数据，找到where列的几个值放进sql去查看，发现某些值走了索引，某些值走的全表扫描。好奇怪。
7，那原因只能是这个列的索引上索引碎片过多喽，然后重建索引，最后发现sql走了索引，速度很快。
8，重建了几天之后，发现相同的问题又出现了，真是奇怪了。重新收集下表的统计信息，速度变的很快。原来这张表每天都在插入大量的数据，然后写了个收集这张表统计信息的脚本，然后做个计划任务，每天晚上11点半准时执行这个脚本。
9，过来2天之后，这个问题又出现了。这时候灵机一动，看了一下服务器的配置16G内存。sga_target只有1G，果断的改大之后，目前效果不错，执行很快。后续有什么问题，再补充。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31447263/viewspace-2139247/ ，如需转载，请注明出处，否则将追究法律责任。
