image.png**
【问题现象】

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

SELECT name, SUM(id)
FROM test1119
WHERE phone IN (…超过300个参数…)
GROUP BY name;

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

image.png
【问题影响范围】

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

【问题原因分析】

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

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

image.png
为什么 FFS 更慢?

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

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

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

【优化方案】

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

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

EXEC DBMS_STATS.GATHER_TABLE_STATS('schema_name', 'test1119');

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

方案二:使用 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 条件,可以有效提升性能;

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

【实测对比】
image.png

【总结建议】

image.png


数据库砖家
1 声望0 粉丝