先查事务状态：执行SELECT @@in_transaction;若返回0说明不在事务中，COMMIT必然无效；再查SELECT @@autocommit;确认是否自动提交模式；最后用SHOW ENGINE INNODB STATUS\G和INNODB_TRX视图定位死锁、锁等待或只读/磁盘满等根本原因。
COMMIT报错但没具体信息，先查事务状态
MySQL 的 COMMIT 本身几乎不会主动报错——所谓“提交失败”，90% 是前面某条 INSERT/UPDATE/DELETE 已经出错了，但应用层没捕获，还硬调了 COMMIT。这时候错误可能被掩盖，只看到连接断开或超时。
实操建议：
- 执行
SELECT @@in_transaction;，返回0说明当前根本不在事务中，COMMIT必然无效 - 执行
SELECT @@autocommit;，若为1，则每条语句都是自动提交，显式BEGIN后没报错却没COMMIT，是误判“失败” - 用
SHOW ENGINE INNODB STATUS\G查最近一次死锁或异常，重点关注LATEST DETECTED DEADLOCK区域
COMMIT卡住不动（hang），重点查锁和阻塞
现象是客户端一直等、没报错、超时才断开，本质是事务在等锁释放，而持锁者迟迟不提交。这不是你代码的问题，而是别人卡住了你。
实操建议：
- 立刻运行
SELECT * FROM information_schema.INNODB_TRX\G，看TRX_STATE是LOCK WAIT还是RUNNING；如果是前者，说明它正等着谁释放锁 - 配合
SELECT * FROM information_schema.INNODB_LOCK_WAITS;（5.7 及以前）或SELECT * FROM performance_schema.data_locks;（8.0+），找出BLOCKING_TRX_ID对应的事务 - 检查那个阻塞事务的
TRX_STARTED时间——如果早于 5 分钟，大概率是开发忘了COMMIT或程序异常退出没回滚 - 临时缩短等待时间暴露问题：
SET SESSION innodb_lock_wait_timeout = 5;
报 ERROR 1213 / “Deadlock found” ，不是 bug 是常态
这个错误不是配置错了，是 InnoDB 主动检测到死锁后回滚了你这个事务。它在保护数据一致性，你得配合重试。
实操建议：
- 应用层必须捕获错误消息里含
Deadlock found when trying to get lock或错误码1213，不能当普通异常吞掉 - 重试最多 3 次，每次前加随机延迟（如
sleep(0.05 + rand() * 0.1)），避免所有重试请求立刻撞上同一把锁 - 检查多表更新顺序：事务 A 先改
users再改orders，事务 B 反过来，就是死锁温床；统一按主键升序访问可大幅降低概率 - 确认所有
WHERE条件都走了索引——全表扫描会锁整张表，极大抬高死锁风险
报 ERROR 1792 / “READ ONLY transaction” ，别急着改权限
这个错和用户权限无关，是 MySQL 实例被设成了只读模式。哪怕你是 root，只要 super_read_only = ON，就什么都写不了。
实操建议：
- 一步查清：
SELECT @@read_only, @@super_read_only;，两个都必须是0才能写 - 云数据库（如阿里云 RDS、腾讯云 CDB）常在控制台静默开启
super_read_only，改my.cnf不生效，得进控制台关开关 - 解除顺序很重要：必须先
SET GLOBAL super_read_only = OFF;，再SET GLOBAL read_only = OFF;，反过来会失败 - 磁盘满也会伪装成只读错误：
ERROR 1030 (HY000): Got error 28 from storage engine对应系统ENOSPC，记得df -h看磁盘
真正难排查的，往往不是报错那一行 SQL，而是它前面那条没走索引的 UPDATE、那个忘了关的交互式会话、或者存储过程里偷偷执行的 ALTER TABLE —— 它们都在暗处悄悄毁掉你的事务边界。
