**
【问题现象】
在对一张包含 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 条件,可以有效提升性能;
实测:性能由数十秒降至 毫秒级。
【实测对比】
【总结建议】
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。