本文主要是介绍SQL之美第一篇：组合索引巧解错误的BITMAP AND，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
大家好，我是千寻，一名追求SQL优化极限的开发DBA，欢迎大家一起与我共赏SQL之美妙，如有疑问，欢迎留言，共同研究，下面进入正题：
问题描述：接到开发反馈，有一个SQL查询不出来结果，原因是字段【pysts_cd】是varchar2类型，去掉符号‘’ 就可以查出来结果，确认数据库没有问题数据以及各种异常数据（比如null，空值，特殊符号，都不存在）
原SQL：
select *
from qx_prd_psch_d m
where m.bqx_flag = 'spddqx'
and m.is_sq_bqx = '0'
and m.is_del = 0
and m.pysts_cd ='2'
and to_char(m.PAYSE_DT, 'yyyy-mm-dd') = '2019-04-17';
拿到SQL，直接执行确认开发说法无误，观察带上符号‘’于不带的两种执行计划：
可以看到，这里走了位图索引转换，同时两个索引做了合并，谓词条件里面的字段都走了索引，再看看出来结果的SQL执行计划：
对比发现了，RS_QX_PRD_PSCH_D_05这个索引一走就出现问题，单独走索引RS_QX_PRD_PSCH_D_04就没有问题，下面来做验证：
这里使用了to_single_byte函数做了全角转半角，当然，trim也可以，
果然，结果出来了。看到这里，部分同学会想那问题不就解决了，加个函数转换字段【pysts_cd】即可，肯定是还存在问题数据(PS:一般情况，这么解释就可以交任务了)当然没那么简单，哈哈。
开发反馈，这个SQL改动涉及代码很多，工作量太大，不给改，希望在数据库后台就解决了，因此，这里开始深入分析：
首先，确认问题字段类型：
第二步，观察相关索引：
这里稍微总结下：谓词条件一共使用了【 bqx_flag,is_sq_bqx,is_del,pysts_cd,PAYSE_DT】5个字段，那么问题出在哪里呢？有经验的人已经发现了 索引【RS_QX_PRD_PSCH_D_05】一定有问题！
第三步，测试索引问题所在
首先，问题所在pysts_cd字段肯定不能动，那么去掉该组合索引另一个字段试试呢？
结果出来了！同样的执行计划，同样的 Plan Hash Value，为什么会出现这种情况呢？细心的小伙伴已经发现啦，没错 你的想法是正确的！
就是谓词条件的filter里面字段的问题，多说一嘴，
Access：表示对应的谓词条件会影响数据的访问路径（是按照索引还是表）
Filter：表示谓词条件只会起到过滤作用，不会影响数据的访问路径。
难道是问题数据？很多人会被误导：
正好排序第一位是1，跟0不匹配，然后就被filter把后面的全都过滤了，让这部分索引结果是为空，导致两个索引走bitmap and以后结果集是空 ，这个解释也说得通，然而事实并非如此，让我们来修改再看看：
到这里，基本绝大部分人思路已经断了，嘿嘿，下面如何排查呢？
这里，就需要抓取真实执行计划了：
瞬间，问题清晰！【SYS_NC00043$】这个对象一般是oracle处理字符乱码才会出现的，查看IS_DEL类型
，发现ORACLE小BUG，位图索引转换NUMBER(1)类型字段的时候，转换的值是乱码！这里又有BITMAP AND 导致连锁反应，结果集为0！
再次小心求证：
确认无误，问题字段其实并不是【pysts_cd】，反而是【is_del】!
问题明确了，解决方案很简单：
-
干掉索引 【RS_qx_prd_psch_d_04】+【RS_qx_prd_psch_d_05】
-
重建新的组合索引：
既去掉了多个索引的冗余，又提高了SQL的效率，同时解决了开发人员的需求，有效降低他的工作量，收获了开发的崇拜之心，沉浸在SQL美妙的海洋，开心！
优秀的DBA，就该这样！
这篇关于SQL之美第一篇：组合索引巧解错误的BITMAP AND的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
