Navicat的“解释”按钮在事务中默认不工作，仅支持独立单条语句；事务内点击无反应或报错，因EXPLAIN无法预估依赖前序变更的语句，需将目标SELECT剥离为独立语句再执行。
事务中点“解释”按钮没反应，不是功能失效
Navicat 的 解释 按钮在事务块内（比如已执行 BEGIN 或 START TRANSACTION）默认不工作——它只对独立、可预估执行路径的单条语句生效。事务本身是控制逻辑单元，不是查询执行单元，Navicat 不会、也不能为 COMMIT 或 ROLLBACK 生成执行计划。
常见错误现象：BEGIN; SELECT * FROM users WHERE id = 1; 粘贴后点 解释，结果面板空白或报错 Unexpected token BEGIN；或者只对最后一行 SELECT 生效，但忽略前面的事务控制语句。
- 事务开启后，Navicat 实际连接状态已进入“事务模式”，部分数据库（如 MySQL）会禁用
EXPLAIN对非只读语句的支持 -
EXPLAIN本质是优化器预估，而事务中语句可能依赖前序变更（如刚插入的行），导致预估不可靠，Navicat 主动规避这种不一致 - Oracle 和 SQL Server 更严格：事务上下文内调用
EXPLAIN PLAN FOR或图形化 API 会直接报错ORA-01008: not all variables bound或Cannot show execution plan while in transaction
想查事务里某条 SELECT 的执行计划，得单独剥离出来
不能把 SELECT 嵌在 BEGIN ... COMMIT 里再点 解释，必须让它成为独立可执行的语句。
- 复制事务中的目标
SELECT（含所有WHERE条件、JOIN子句），新建一个查询窗口粘贴执行 - 确保该
SELECT不依赖事务内未提交的数据（例如不要查刚INSERT但未COMMIT的临时结果） - 如果原语句用了变量（如
WHERE id = ?），需手动替换成具体值，否则 Navicat 解释时无法绑定参数，返回空结果或语法错误 - MySQL 用户注意：
EXPLAIN FORMAT=JSON在事务中可能被拒绝，剥离后用纯EXPLAIN或EXPLAIN ANALYZE（v8.0.22+）更稳妥
事务回滚失败时看执行计划毫无意义
当 Navicat 提示“事务回滚失败”，问题一定出在锁、连接中断、权限或服务器资源上，而不是查询性能。此时打开 解释 标签页看到的只会是误导性信息，甚至根本打不开。
- 典型场景：事务卡在
UPDATE上因行锁被占，你点解释查这条UPDATE，但 Navicat 实际发的是EXPLAIN UPDATE ...—— 多数数据库不支持对 DML 语句直接EXPLAIN，MySQL 会静默转成SELECT预估，结果完全失真 - SQL Server 中，事务内执行
EXPLAIN等价于触发图形化计划 API，但若连接已处于阻塞/超时状态，API 调用直接失败，Navicat 不提示具体原因，只留空面板 - 真正该查的是数据库日志：
SHOW ENGINE INNODB STATUS（MySQL）、sp_who2（SQL Server）、pg_stat_activity（PostgreSQL），而不是执行计划
Navicat 版本与事务 + 解释的兼容性差异
不是所有 Navicat 版本都平等处理事务上下文中的解释请求。v16.0.14 之前的老版本会在事务中强行尝试解析，导致界面假死；v17.2+ 改为静默禁用按钮，但用户容易误以为是 bug。
- v15.6 及更早：事务中点
解释可能触发Packet for query is too large错误，实际是它把整个事务块当单条语句传给服务端解析 - v16.1.12+：新增检测逻辑，识别到
BEGIN/START TRANSACTION开头就灰掉解释按钮，但没任何提示文案，用户只能靠试错发现 - v17.3.6（当前最新稳定版）：仍不支持事务内解释，但错误反馈更明确——点击后弹出提示
This statement cannot be explained in transaction context
最易被忽略的一点：Navicat 的“解释”功能设计初衷就是服务于**单次查询调优**，它从不打算覆盖事务调试场景。拿它查死锁、查回滚失败、查长事务阻塞，方向就错了。
