慢SQL优化-位图索引

更多请关注：https://t.zsxq.com/fhroW

概述：通过执行计划发现SQL走的是位图索引，进行BitmapAnd操作取两个普通索引扫描结果的交集，修改SQL使其只走一个索引后查询效率提升

执行计划

• 原SQL

explain ( ANALYZE,BUFFERS,COSTS,TIMING,VERBOSE )
select corpid, mobile from crm_mobiles
where 
  mobile in ('12331231',....值很多 省略....,'123131')
  and corpid = 'ww1d790df4462cbe87'
  and deleted = 0;

• 原SQL执行计划
  

BitmapAnd表示取两个Bitmap index scan的交集。
两个Bitmap Index Scan 的结果，分别是 crm_mobiles_search_v1 和 crm_mobiles_corp_deleted_sales_customer_mobile_v1 索引的扫描结果，(下文简称索引A和索引B)

索引A扫描行数77782行，耗时90ms
索引B扫描行数565973行，耗时1931ms
显然，取交集操作的情况下，这个SQL的瓶颈在于索引B，如果只走索引A则会更快。

索引B的字段为: corpid, mobile, deleted, sales_id, customer_id
索引A的字段为: mobile

• 优化后SQL

explain ( ANALYZE,BUFFERS,COSTS,TIMING,VERBOSE )
select corpid, mobile from crm_mobiles
where 
  mobile in ('12331231',....值很多 省略....,'123131')
  and corpid || ''= 'ww1d790df4462cbe87'
  and deleted = 0;

字段corpid后面拼接空字符串，数据库引擎认为这是一个新的字符串，不会走corpid的索引。

• 优化后的执行计划
  

优化后仍然使用了Bitmap索引但是没有走BitmapAnd，只扫描了一个索引。就比较快。

注意

查看执行计划一定要在原环境、原参数的情况下查看。修改参数、改变环境导致数据量变化、扫描行数变化，都会使执行计划变化。

关于Bitmap index

数据库在查询优化过程中可能会选择使用位图索引（通过Bitmap Index Scan）来提高效率。这个选择通常发生在涉及多个条件组合的查询中，数据库可以通过位图操作快速处理交集、并集等条件组合。

Bitmap Index 是一种索引类型，它以位图（bitmap）的形式存储索引值，位图索引存储的是每个不同值的位图。每个位图的每一位表示数据库中的一行，位图中的值为1表示该行包含该索引值，为0表示不包含。

普通索引（如B-tree索引）通常以树形结构存储数据，适用于范围查询、精确匹配以及高基数（不同值数量多）的列。它通过层级结构快速找到目标值，从根节点到叶子节点，逐步缩小搜索范围。

BitMap的优势：批量处理、减少IO、通过位图实现数据过滤和排序，效率更高。