最可靠方式是查information_schema.INNODB_TRX表，筛选trx_state = 'ACTIVE'且trx_started超时（开发60秒、生产120秒）的事务；trx_query为空仍持锁占资源，需结合sys.schema_table_lock_waits或performance_schema定位并KILL blocking_pid。
未提交事务不会自己报错，但会悄悄拖慢DDL、卡住后续DML、抬高undo压力——最可靠的方式是查information_schema.INNODB_TRX，而不是SHOW PROCESSLIST。
查INNODB_TRX找真正活跃的未提交事务
很多“Sleep”连接背后挂着没提交的事务，SHOW PROCESSLIST只显示当前语句，而INNODB_TRX才记录事务真实生命周期。关键筛选条件是：trx_state = 'ACTIVE'（排除已提交/回滚状态），再结合trx_started判断时长。
- 开发环境建议阈值设为
60秒，生产环境从120秒起查 -
trx_query为空不等于没事——说明SQL执行完了但没发COMMIT，锁和undo仍被占用 -
trx_mysql_thread_id可直接用于后续KILL，别用PROCESSLIST.ID去匹配（可能已断开） - ORM如Spring的
@Transactional若被try-catch吞掉异常且没手动回滚，就会留下这种trx_state = 'ACTIVE'+trx_query = NULL的静默挂起
用sys.schema_table_lock_waits定位MDL阻塞链
当ALTER TABLE卡住不动，大概率不是DDL本身慢，而是某个未提交事务持着SHARED_WRITE或EXCLUSIVE MDL锁。MySQL 5.7+自带sys.schema_table_lock_waits，比手拼performance_schema.metadata_locks快得多。
- 输出中
blocking_pid就是持锁线程ID，sql_kill_blocking_connection字段可直接复制执行 - 如果
sys库不可用或权限不足，立刻切到performance_schema.metadata_locks查LOCK_STATUS = 'GRANTED'且LOCK_TYPE含MDL的记录 - 注意区分：持有MDL锁的线程
PROCESSLIST_INFO常为空或仅SELECT，不代表它没在干活——事务一开，MDL锁就上了
KILL前必须确认是否真能安全终止
KILL QUERY对未提交事务无效，它只中断当前语句，事务仍活跃，MDL锁不会释放。必须用KILL，但得先确认这不是一个正在写大量数据的业务事务。
- 查
performance_schema.threads匹配PROCESSLIST_INFO：若为空或只有SELECT，基本无实际操作；若显示UPDATE ... WHERE且TRX_ROWS_MODIFIED > 0，需谨慎评估回滚成本 - 用
SHOW ENGINE INNODB STATUS\G查对应trx_id，看mysql tables in use和locked tables是否都为0——是则可安全KILL -
KILL触发回滚，若已修改数百万行，回滚本身可能持续几分钟，期间仍阻塞其他DDL
别漏掉只读模式和磁盘满这两类“假未提交”
有些事务看似卡在COMMIT，其实是数据库层面拒绝写入，根本不是事务逻辑问题。
- 执行
SELECT @@read_only, @@super_read_only;，两个变量必须同时为OFF才能提交；云RDS控制台开关可能静默设置，改配置文件无效 - 磁盘满或挂载为
ro时，COMMIT阶段写redo/doublewrite/undo失败，错误常被掩盖成超时或连接断开，查dmesg或df -h更直接 -
innodb_lock_wait_timeout设太小（如5）会让阻塞快速暴露，但不能解决根本问题——它只是帮你更快发现那个trx_started早于当前时间几分钟的ACTIVE事务
真正难的不是找到未提交事务，而是判断它到底该提交、回滚，还是继续观察——比如一个批处理事务刚跑完前90%数据，杀掉就得重来；而一个空挂3小时的BEGIN，不杀它DDL永远动不了。
