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

【问题描述】

测试表数据量约 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 后依然无效，执行时间仍然偏长。

【问题分析】

通过执行计划分析发现：

优化器使用了复合索引;

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

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

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

【解决思路】

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

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

【推荐做法】

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

ALTER INDEX IND_TEST1119_ID_PHONE INVISIBLE;

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

CREATE INDEX IND_TEST1119_PHONE_ID ON TEST1119(PHONE, ID);

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

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

【实测效果对比】

【适用版本】

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

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

【总结建议】

ITPub博客

YashanDB｜复合索引用了也慢？IN 参数太多时建议这样调