达梦数据库参数嗅探导致 SQL 超时排查与优化指南
1. 问题背景与定义
1.1 什么是参数嗅探
参数嗅探是指数据库优化器在编译 SQL 语句时，使用了第一次执行（或特定次执行）传入的参数值来生成执行计划。由于不同参数值对应的数据分布（选择性）不同，导致该执行计划对于某些参数是高效的，而对于另一些参数则是低效甚至导致超时的。
1.2 现象描述
- 间歇性超时：相同的 SQL 语句，传入参数 A 执行很快，传入参数 B 执行超时。
- 执行计划变动：使用占位符（?）生成的执行计划与代入具体参数值生成的执行计划不一致。
- 预估行数偏差：执行计划中某步骤的 Estimate Rows（预估行数）与实际行数相差巨大（通常相差 1-2 个数量级以上）。
2. 排查思路与步骤
2.1 第一步：对比执行计划
获取两份执行计划进行对比：
- 占位符计划：直接在 SQL 客户端执行带有 ? 或 :param 的 SQL，查看优化器生成的“通用计划”。
- 参数赋值计划：执行时填入导致超时的具体参数值，查看“特定计划”。
关注点：
- 访问路径差异：是否从索引扫描变更为全表扫描（SSCN）？
- 连接方式差异：是否从嵌套循环变更为哈希连接，反之亦然？
- 驱动顺序差异：驱动表是否发生了改变？
2.2 第二步：分析数据分布
检查超时参数对应字段的数据分布情况。
-- 示例：检查字段值分布
SELECT COUNT(*) FROM MAIN_TABLE WHERE PLACE_CODE LIKE '340000000000%';
SELECT COUNT(*) FROM MAIN_TABLE WHERE PLACE_CODE LIKE '340104001000%';- 倾斜性判断：如果超时参数（如省级代码 '340000...'）覆盖了表中 50% 以上的数据，而正常参数（如街道代码）仅覆盖 0.1%，则基本确认为参数嗅探导致优化器选择了错误的路径。
2.3 第三步：定位性能瓶颈点
在超时的执行计划中，寻找以下标志性操作：
- 大量回表：BLKUP2 操作上估算行数极大。意味着通过索引找到了大量数据，不得不频繁回表查询其他字段，效率低于全表扫描。
- 排序溢出：SORT3 或 HAGR2（哈希聚合）操作占用大量内存，甚至溢出到磁盘。
- 无效索引扫描：索引扫描范围很大，但父节点 SLCT2（过滤）过滤掉了绝大部分数据。说明索引列顺序不当，未能利用索引过滤。
3. 通用解决方案
针对参数嗅探导致的性能问题，按照推荐程度排序提供以下解决方案：
3.1 方案一：索引优化（基础治理）
原理：通过建立高效的复合索引，减少优化器对“数据量预估”的依赖，无论选择哪种访问路径，都能快速定位数据。
规范：
- 等值列优先：将 =、IN 操作的列放在索引最左侧。
- 范围列次之：将 >=、<=、LIKE 'xxx%' 放在等值列之后。
- 避免回表：如果查询列较少，可考虑将查询列包含在索引中。
案例：
-- 原索引：仅支持地点，导致回表过滤时间
INDEX(PLACE_CODE)
-- 优化索引：支持地点+时间的组合过滤
CREATE INDEX IDX_PLACE_TIME ON T_MEDIATION_CASE(PLACE_CODE, CREATE_TIME);3.2 方案二：SQL 改写与 HINT 强制（根治手段）
原理：当索引无法完全解决问题（如连接顺序选择错误）时，通过 HINT 固定执行计划，强制优化器使用最优路径。
3.2.1 固定连接方式
对于统计分析类 SQL（处理数据量大），强制使用 哈希连接 通常比嵌套循环更稳定，不会因参数值不同而产生巨大的性能波动。
/*+ USE_HASH(table_a table_b) */
SELECT ... FROM table_a INNER JOIN table_b ON ...3.2.2 固定驱动表
明确指定小表驱动大表。
/*+ LEADING(small_table large_table) */3.2.3 逻辑等价改写
- DISTINCT JOIN 改 EXISTS：
- 原逻辑：先关联去重，大数据量下排序/哈希开销大。
- 新逻辑：利用 EXISTS 的“短路”特性，找到一条即停，适合外表数据量小的场景。
-- 改写前
SELECT * FROM MAIN_TABLE m JOIN (SELECT DISTINCT id FROM DETAIL_TABLE ...) d ON m.id = d.id
-- 改写后
SELECT * FROM MAIN_TABLE m WHERE EXISTS (SELECT 1 FROM DETAIL_TABLE d WHERE d.id = m.id ...)
- 窗口函数改聚合：- 原逻辑：ROW_NUMBER() OVER(...) 需要全量排序，易内存溢出。- 新逻辑：使用 MAX(...) KEEP (DENSE_RANK FIRST ...) 聚合函数，利用 Hash Aggregate 代替 Sort，内存占用恒定。```sql
-- 改写前
ROW_NUMBER() OVER(PARTITION BY id ORDER BY time DESC)-- 改写后
MAX(col) KEEP(DENSE_RANK FIRST ORDER BY time DESC)3.3 方案三：绑定变量窥探控制（系统层面）
注意：此方案影响全局，需谨慎评估。
达梦数据库参数USE_PLN_POOL控制是否重用执行计划。
- 如果是该参数导致无法生成适合当前参数的计划，可咨询 DBA 是否需要在 Session 级别或 Statement 级别禁用计划重用（通常不推荐，会牺牲通用性能）。
4. 典型案例复盘
案例 1：地域代码导致的索引失效
- 场景：查询某省或某街道的案件。
- 问题：省级代码覆盖 60万行数据，优化器误判使用“嵌套循环 + 回表”，导致 60万次随机 I/O。
- 解决：
- 创建 (PLACE_CODE, CREATE_TIME) 复合索引。
- 使用 /*+ USE_HASH(...) */ 强制哈希连接，避免随机 I/O。
案例 2：窗口函数内存溢出
- 场景：统计每个分组的最新一条记录。
- 问题：ROW_NUMBER 对大数据集排序导致内存溢出。
- 解决：改写为 MAX(...) KEEP(DENSE_RANK FIRST ...) 聚合语法，消除排序操作。
5. 总结
排查参数嗅探问题的核心在于“稳定性”。
- 索引要稳：确保索引能覆盖最核心的过滤条件，减少回表带来的不确定性。
- 计划要稳：对于复杂的分析查询，不要依赖优化器的自动选择，通过 USE_HASH、LEADING 等 HINT 锁定执行路径，使其在任何参数下都能平稳运行。
- 逻辑要简：优先使用 EXISTS 代替 JOIN DISTINCT，优先使用聚合代替窗口函数排序。
通过以上步骤，可以系统性解决达梦数据库因参数嗅探引发的 SQL 超时问题。