Navicat 17 不触发也不定位锁升级，真正原因在 MySQL 内核；需绕过界面直查 SHOW PROCESSLIST、INNODB_TRX 和 INNODB_LOCK_WAITS，重点识别 State=“Waiting for table metadata lock”、Query 持锁及 Sleep 超 300 秒的隐式事务。
Navicat 17 本身不触发锁升级，也不会“定位”锁升级源头——它只是把你的 SQL 交出去执行；真正导致锁升级（如行锁升表锁、MDL 锁长期持有）的是 MySQL 内核对事务、语句类型和隔离级别的综合判断。定位必须绕过 Navicat 界面，直查服务端状态。
为什么 Navicat 的「活动监视器」找不到锁升级源头
Navicat 自带的「活动监视器」或「进程列表」默认只刷新当前快照，且会过滤掉 State 为空、Command = Sleep、Info 为空但 Time > 300 秒的连接——而这恰恰是隐式事务未提交、正安静持有 MDL 写锁的典型特征。它也不展示 INNODB_TRX 中的 trx_state 和 trx_started，无法区分“刚启动的合法事务”和“挂了 8 分钟的僵尸事务”。
- Navicat 右键 →「命令列界面」执行
SHOW PROCESSLIST后，重点盯三类行：State含Waiting for table metadata lock（等待者）、State是Query且Info含SELECT ... FOR UPDATE或UPDATE（持锁 DML）、Command是Sleep但Time> 300（极可能隐式事务没提交） - 别信「活动监视器」里标为 idle 的连接——MySQL 的
Sleep状态下，只要事务没 COMMIT/ROLLBACK，锁就还在 - Navicat 的「查询分析器」能聚合慢查询，但无法关联锁等待链；它看到的“最耗时查询”可能是被卡住的结果，而非原因
用 Navicat 执行三步诊断 SQL（必须手动输）
在 Navicat 新建查询窗口，依次执行以下三条语句，顺序不能错：
- 查谁在等：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;—— 有结果说明存在锁等待链，记下BLOCKING_TRX_ID - 查谁在持：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_ID = '<code>BLOCKING_TRX_ID'\G —— 看TRX_STATE是否为RUNNING，TRX_STARTED是否超 5 分钟，TRX_QUERY是否是未提交的UPDATE或SELECT FOR UPDATE - 查它连的线程：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = <code>TRX_MYSQL_THREAD_ID; —— 确认INFO字段是否为空或仅含BEGIN，STATE是否为空
如果第三步查到的 INFO 是空、STATE 是空、TIME > 300，基本可断定：这是 Navicat 用户点过「保存修改」后关了窗口，或执行完一条 SELECT FOR UPDATE 没手动 COMMIT，导致事务一直挂着。
哪些 Navicat 操作最容易引发锁升级
不是所有 SQL 都会升级，但以下操作在 Navicat 中高频出现、且极易踩坑：
- 点「保存修改」改字段类型：Navicat 自动生成
ALTER TABLE ... MODIFY COLUMN，对千万级表会全程加 MDL 写锁，期间所有读写都被阻塞；它不拆解、不提示、不降级 - 在表设计视图中勾选「设为主键」再取消：预览显示
DROP PRIMARY KEY，但若该主键被外键引用，执行时失败，事务回滚卡住，锁却没释放 - 用「查询编辑器」执行带
FOR UPDATE的 SELECT 后，直接切走干别的事——Navicat 不自动 COMMIT，锁持续持有 - 导出大表时勾选「导出 INSERT 语句」：Navicat 默认逐行 SELECT，每行都可能触发间隙锁，尤其配合
REPEATABLE READ隔离级别时，极易扩大锁定范围
真正要防锁升级，不是靠 Navicat 功能开关，而是：改结构必用 pt-online-schema-change，带 FOR UPDATE 的语句必须显式配 COMMIT 或 ROLLBACK，导出大表改用「导出数据到文件」而非 INSERT 脚本。
SQL 预览 ≠ 锁行为预览，这点最容易被忽略
Navicat 17 的「SQL 预览」标签只告诉你语法上会发什么语句，完全不反映锁粒度、持有时间或升级条件。比如：
- 预览显示
MODIFY COLUMN name VARCHAR(200)，看起来 harmless，但实际执行时 MySQL 会对整张表加 MDL_EXCLUSIVE 锁，持续到 DDL 完成 - 预览里
ADD INDEX idx_name ON t(col)没报错，但如果col上已有全文索引，MySQL 8.0+ 会拒绝执行，而事务已开启，锁卡住 - 你改了字段名，预览切为
CHANGE COLUMN，这比MODIFY更重——它隐式重建字段，锁持有时间翻倍
所以，别看预览没报错就点保存。真正关键的是：这条语句在目标表数据量、引擎、版本下的实际锁行为，Navicat 从不提示，得你自己查文档或测试环境验证。
