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】!

问题明确了，解决方案很简单：

1. 干掉索引 【RS_qx_prd_psch_d_04】+【RS_qx_prd_psch_d_05】

2. 重建新的组合索引：

既去掉了多个索引的冗余，又提高了SQL的效率，同时解决了开发人员的需求，有效降低他的工作量，收获了开发的崇拜之心，沉浸在SQL美妙的海洋，开心！

优秀的DBA，就该这样！