【关键词】复合索引、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 大量过滤场景的响应效率。
【总结建议】
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。