踩坑CBO，解决那些坑爹的SQL优化问题_PART7

接PART6：http://chinaunix.net/uid-7655508-id-5834621.html2.5 坑爹写法CBO无能为力问题  结构优良的SQL能够更易被CBO理解，从而更好地进行查询转换操作，从而为后续生成最佳执行计划打下基础，然后实际应用过程中，因为不注重SQL写法，导致CBO也无能为力。下面以分页写法案例作为探讨。低效分页写法：原写法最内层根据use_date等条件查询，然后排序，获取rownum并取别名，最外层使用rn规律。问题在哪？分页写法如果直接可在排序后直接rownum获取（两层嵌套），如果需要获取区间值，在最外层获取>,>=（三层嵌套）。此语句获取而使用三层嵌套，导致无法使用分页查询STOPKEY算法，因为rownum会阻止谓词推入，导致外层的rn无法推入到第二层，因此执行计划中没有STOPKEY操作。分页只需要2层嵌套，done_date列有索引，根据条件done_date>to_date(‘20150916’,‘YYYYMMDD’)和只获取前20行，可高效利用索引和STOPKEY算法，改写完成后使用索引降序扫描，执行时间从1.72s到0.01s,逻辑IO 从42648到59，具体如下：高效分页写法应该符合规范，并且能够充分利用索引消除排序。2.6 CBO BUG问题  CBOBUG出现比较多的就是在查询转换中，一旦出现BUG，可能查找就比较困难，这时候应该通过分析10053或者通过使用SQLT XPLORE快速找到问题根源。如下例：  这个表的oper_type有索引，并且条件oper_type>’D’or oper_type走索引较好，但是实际上ORACLE却走了全表扫描，通过SQLT XPLORE快速分析：  其中上面2个是走索引的执行计划，点进去： 很显然，_fix_control=8275054很可疑，通过查询MOS： 转换成ab，很显然使用不了索引了，可以通过关闭此8275054解决。未完待续，见PART8：http://chinaunix.net/uid-7655508-id-5834710.html