navicat的“解释”对动态sql不可信，因其不展开变量、不模拟参数绑定，导致执行计划失真；应复制应用生成的真实sql（含具体值）手动分析。
动态SQL在Navicat里点“解释”基本没用——它不展开变量、不模拟参数绑定，看到的执行计划大概率是错的。
为什么Navicat对动态SQL的EXPLAIN结果不可信
Navicat 的「解释」按钮本质是把当前文本原样发给数据库执行 EXPLAIN（MySQL）、EXPLAIN PLAN FOR（Oracle）或图形化接口（SQL Server）。但动态SQL通常含占位符（如 ?、:id）、拼接逻辑或运行时变量，Navicat 不会做任何值替换或预编译模拟。
- MySQL 中写
WHERE status = ?→EXPLAIN无法判断实际走哪个索引分支，type可能显示ALL或range完全取决于优化器“猜” - Oracle 使用
EXECUTE IMMEDIATE拼接的语句 → Navicat 调用EXPLAIN PLAN FOR时若未显式绑定变量，PLAN_TABLE里可能只存语法树，无真实访问路径 - SQL Server 存储过程中带
sp_executesql→ Navicat 点“解释”只作用于外层包装语句，根本进不去动态部分
真实场景下怎么拿到靠谱的执行计划
必须绕过 Navicat 的自动封装，手动构造可复现、带具体值的等价语句再分析：
- 把应用中生成的最终 SQL 字符串完整复制出来（比如日志里打印的
SELECT * FROM orders WHERE user_id = 12345 AND created_at > '2026-08-01'），粘贴进 Navicat 查询窗口，再点「解释」 - PostgreSQL 用户慎用
EXPLAIN ANALYZE：如果原始动态 SQL 是UPDATE，你手动替换成带值的UPDATE后再加EXPLAIN ANALYZE，它会真执行一次——先备份或切到测试库 - SQL Server 若依赖
OPTION (RECOMPILE)生成计划，手动补上该 hint 再点「解释」，否则 Navicat 拿到的是缓存计划，和动态执行时的不一致 - Oracle 需确认是否启用了绑定变量窥探（
_optim_peek_user_binds=TRUE），否则即使你手动填了值，DBMS_XPLAN.DISPLAY输出仍可能按“平均分布”估算
容易被忽略的三个断点位置
动态SQL的性能陷阱常藏在 Navicat 执行计划看不到的地方：
-
key_len显示用了联合索引前两列，但第三列条件是UPPER(name) = 'ABC'→ Navicat 的EXPLAIN不报错，但实际索引失效；得看Extra是否出现Using where而非Using index - MySQL 中
IN子句动态拼了 500 个 ID → Navicat 的rows估算可能崩掉（显示 1 行），但真实执行扫了百万行；必须用EXPLAIN FORMAT=JSON查filtered字段验证选择率 - SQL Server 动态语句里用了临时表（
#tmp），Navicat 图形化计划里根本不会渲染其扫描步骤——因为临时表元数据在执行前不存在，计划只反映主查询骨架
动态SQL的执行计划准确性，从来不在 Navicat 界面里校验，而在你能否还原出那个带真实值、无变量、可独立执行的最小可测语句。别信「解释」标签页第一眼看到的 type 和 rows，先确认它是不是你真正要跑的那一句。
