先说说为什么要搞出Adaptive Cursor Sharing这么个东西。
11G以前一直存在一个问题，就是SQL在第一次硬解析的时候，优化器会窥探绑定变量的值，根据这个值来生成执行计划。其实对于数据均匀分布的情况来说，这个窥探也没啥大问题，之所以说没啥大问题，其实还是有我问题，我有点罗嗦了，那是因为范围查询的话情况就不一样了，即使你的单个值没倾斜分布，但是范围来说，也可能存在数据倾斜。比如你的id字段最小值是1，最大值是1W，但是从2-9000都是没有值的，那么这样的情况，如果你对id进行范围查询，也会涉及到执行计划依赖于你传输的绑定变量。由于11G以前，在第一次窥探玩绑定变量后，执行计划就产生在共享池里了，后续的同样的SQL都会使用这个执行计划，而不去管传入的值到底是什么，现在的执行计划是不适合这个变量值。
我很早就思考过这个问题，要解决这个问题，面临几个要解决的难题：
1）既然他们的执行计划对绑定变量敏感，那么就对有直方图的列，每次都窥探他的值，如果执行计划有变化，那么就新生成一个执行计划
2）上面的如果可行，那么问题来了，现在对于这个SQL有2个执行计划了，可是对于后续的SQL也还是每次都要去窥探绑定变量的值，然后生成执行计划跟现有的比，还是有什么巧妙的办法？ORACLE搞了一个基数的概念出来，也就是v$sql_cs_selectivity 这个试图内记录的内容。对每个有数据倾斜的列计算一个选择率出来，只要在某个选择率范围内的，就可以直接复用这个执行计划。比如id=1执行计划走了索引，选择率是0.1，id=2经过计算也走了索引，选择率是0.5，那么后续来的所有SQL，经过计算后，只要选择率在0.1-0.5之间的，都可以直接复用这个执行计划。
上面的想法貌似不错，但是存在一些问题：
1）每次都要对SQL里涉及到直方图的列，都要去窥探它的绑定变量，计算选择率，代价还是比较高啊。其实对于大多数的列，即使存在直方图，他们的执行计划也是一样的。为了解决这个问题，ORACLE设计出来了is_bind_sensitive，v$sql_cs_histogram 两个东东，第一个值代表了这个值对于绑定变量是否敏感的，第二个视图的作用，主要是用在如果由于这个列上的值的不同，导致结果集大范围波动的，就在这个视图的相关条目里标记。
-----未完，待续
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22034023/viewspace-762834/ ，如需转载，请注明出处，否则将追究法律责任。
