聊聊Oracle自适应查询优化

成也AQO败也AQO

因为工作的原因，我们接触到的客户大部分是金融和运营商行业，这些客户有个最大的特点是追求稳定，对于使用数据库新特性持保守的态度，不会轻易尝试某些可能会导致生产系统不稳定的新特性。上线前通常都会将一些新特性禁用，避免上线后可能会由于这些新特性而导致性能出现抖动。

但是近期遇到的一个case，却颠覆了我对这些新特性的看法。

最近我们在帮客户分析一条SQL的性能问题，过程中发现由于数据库的Adaptive Plan参数是默认的开启状态，产生了比较多的子游标，当使用某个条件时就会出现性能下降的情况。作为本能的反应，我们建议客户关闭Adaptive Plan功能，给出的理由是“虽然未必是最优的，却是我们能接受的稳定性能”。修改完参数客户重新测试执行了相关的业务模块，之前有问题的SQL按照预期很顺利的执行完成，但是又出现了新的情况，有另一条在之前的测试中秒级执行的SQL这次却整整用了2000+秒才执行完成。这不由得让我们重新审视Adaptive Plan带给数据库的正面影响。

什么是 AQO (自适应查询优化)

为了SQL语句能够始终以最优的执行计划执行，Oracle在不断的探索和革新。从9i的绑定变量Peeking，到11g的ACS和Statistics Feedback，在12c中则引入了Adaptive Query Optimization。

Statistics Feedback在SQL第一次执行时，根据统计信息生成的执行计划执行SQL，执行过程中执行计划不能改变，如果统计信息不准确，在SQL第一次执行时可能就会引起灾难性的问题。而且，Statistics Feedback生成的数据只能保存在内存中而不能固化下来，如果过程中