写点什么

YashanDB|IN 参数超 300 个,查询突然变慢? 问题可能出在执行计划上

作者:数据库砖家
  • 2025-05-13
    广东
  • 本文字数:571 字

    阅读完需:约 2 分钟

【问题现象】

在对一张包含 200 万数据量的测试表执行如下 SQL 时,查询性能明显变慢:

SELECT name, SUM(id)FROM test1119WHERE phone IN (…超过300个参数…)GROUP BY name;
复制代码

执行耗时远超预期,达到数十秒甚至更长。

【问题影响范围】

YashanDB 版本:23.2.8.100 及以下所有版本

【问题原因分析】

通过 EXPLAIN 分析发现,SQL 使用了:

INDEX FAST FULL SCAN(FFS)
复制代码

虽然表的 phone 字段已建立索引,但在 IN 参数较多(超过 300 个)时,优化器选择了 快速全索引扫描(FFS),而非更高效的 INDEX RANGE SCAN


为什么 FFS 更慢?

FFS 会完整扫描整个索引,再进行条件过滤;

IN 中参数越多,匹配开销越大;

对于分布不均或数据密集的字段,这种方式会显著拖慢查询。

【优化方案】

方案一:收集最新统计信息

通过重新收集统计信息,有机会使优化器自动选择更优的执行路径:

EXEC DBMS_STATS.GATHER_TABLE_STATS('schema_name', 'test1119');
复制代码

收集后重新执行 SQL,查看是否走上 INDEX RANGE SCAN。

方案二:使用 HINT 强制执行 INDEX RANGE SCAN

若自动优化无效,可通过 SQL HINT 强制指定执行路径:

SELECT /*+ INDEX_RS_ASC(test1119 phone) */name, SUM(id)FROM test1119WHERE phone IN (…)GROUP BY name;
复制代码

INDEX_RS_ASC 表示按索引升序范围扫描;

对于大批量 IN 条件,可以有效提升性能;

实测:性能由数十秒降至 毫秒级

【实测对比】

【总结建议】


用户头像

还未添加个人签名 2025-04-09 加入

还未添加个人简介

评论

发布
暂无评论
YashanDB|IN 参数超 300 个,查询突然变慢?问题可能出在执行计划上_数据库·_数据库砖家_InfoQ写作社区