【问题现象】

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

SELECT name, SUM(id)
FROM test1119
WHERE 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 test1119
WHERE phone IN (…)
GROUP BY name;

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

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

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

【实测对比】

【总结建议】

ITPub博客

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