【关键词】复合索引、IN 参数、执行计划、性能调优

image.png
【问题描述】

测试表数据量约 200 万,在 ID 和 PHONE 字段上建立了复合索引:


CREATE INDEX IND_TEST1119_ID_PHONE ON TEST1119(ID, PHONE);

执行以下 SQL 时性能较差:

SELECT name, SUM(id)
FROM test1119
WHERE id > 50000 AND phone IN (…大于300个参数…)
GROUP BY name;

尝试使用 NO_INDEX_FFS HINT 后依然无效,执行时间仍然偏长。

image.png
【问题分析】

通过执行计划分析发现:

优化器使用了复合索引;

先用索引过滤 id > 50000.再对 phone in (...) 进行 filter;

因 in 参数过多,过滤代价过高,导致性能下降;

无法通过 hint 强制规避执行路径问题。

image.png
【解决思路】

复合索引的顺序会影响执行计划的使用策略。若 id 在前、phone 在后,则优化器优先处理 id 过滤条件。

但本场景下,phone in (...) 是主过滤条件,应将其放在复合索引前面。
image.png

【推荐做法】

步骤一:将原有复合索引设为不可见

ALTER INDEX IND_TEST1119_ID_PHONE INVISIBLE;

步骤二:新建以PHONE为首的复合索引

CREATE INDEX IND_TEST1119_PHONE_ID ON TEST1119(PHONE, ID);

步骤三:观察执行计划变化

此时执行计划将优先按 phone in (...) 条件定位,再结合 id > 50000 筛选,命中数据量显著减少,性能提升明显。
image.png

【实测效果对比】
image.png

【适用版本】

问题存在于 YashanDB 所有当前版本;

建议提前设计索引顺序,提升 IN 大量过滤场景的响应效率。

【总结建议】

image.png


数据库砖家
1 声望0 粉丝