当发现事务被自动回滚时，许多人的第一反应往往是“内存溢出”。但实际上，MySQL并不会因为内存不足就直接抛出ROLLBACK。所谓的“自动回滚”，绝大多数情况下是上层应用（例如 Java Spring、PHP 脚本）捕获到具体错误后主动触发的，或者是 mysqld 进程被 Linux 的 OOM Killer 直接杀掉，导致未提交的事务丢失。真正需要关注的是，错误日志中是否出现Out of sort memory、Cannot allocate memory或者Killed这些明确线索。
事务自动回滚真的是内存溢出造成的吗？
并非如此。MySQL 不会因为“内存不足”而直接触发回滚。所谓的“自动回滚”，通常是上层应用（如 Java Spring、PHP 脚本）捕获到具体错误后主动执行回滚，或是 mysqld 进程被 OOM Killer 杀掉导致未提交事务丢失。真正需要排查的是错误日志里是否出现 Out of sort memory、Cannot allocate memory 或 Killed 这类明确线索。
排查问题先看日志，不要盲目调整参数
打开 MySQL 的错误日志（通常位于 /var/log/mysql/error.log 或 mysqld.err），重点搜索以下几个关键词：
Out of sort memory→ 指向sort_buffer_size不足，不要急于调参，先尝试优化索引Killed（单独一行，没有堆栈信息）→ 大概率是 Linux OOM Killer 所为，可配合执行dmesg -T | grep -i "killed process"进一步确认Lock wait timeout exceeded→ 锁超时，与内存完全无关，应追查阻塞源头Unknown error或静默退出 → 检查是否误开了innodb_force_recovery（值 > 0 会跳过 undo 解析，导致回滚失效）
sort_buffer_size 设置多少才合理？
sort_buffer_size 是每个连接独占的内存，设置过大反而容易引发系统级 OOM。调整前必须满足以下三个条件，缺一不可：
- EXPLAIN 显示该 SQL 已经使用了索引（
type为ref/range），且Extra列不包含Using filesort - 扫描行数（
rows）在 5 万以内，但排序结果集仍然较大（例如需要取 TOP 1000） - 活跃连接数可控（例如稳定在 50 以内），避免总内存占用超出物理限制
建议从 512K 开始尝试，逐步增加到 2M；一旦超过 4M 就应保持警惕——此时更应当检查是否遗漏了覆盖索引，而不是继续分配更多内存。
遇到大事务回滚卡死，切勿直接 KILL，先缓解压力
正在回滚的大事务（尤其是涉及百万级更新的场景），KILL 不仅无法加速，还会让 InnoDB 在后台继续清理的同时阻塞新连接。稳妥的应对方法如下：
- 从
INNODB_TRX中查出trx_mysql_thread_id，执行KILL后观察INNODB_TRX.trx_state是否变为ROLLING BACK，确认事务确实在推进 - 临时降低并发压力：将
innodb_buffer_pool_instances设为 CPU 核心数（例如 8），减少内部资源争用 - 允许后台异步清理：对于已知需要回滚的事务，提前执行
KILL，InnoDB 会在空闲时分批处理，不会阻塞前台操作 - 禁用事务中一切耗费内存的操作：
SLEEP()、SELECT ... INTO OUTFILE、大型结果集的GROUP BY—— 这些操作会挤占 undo 页缓存，拖慢回滚进程
最容易被忽视的一步：重启前务必确认 innodb_force_recovery 是否还残留在配置文件中。哪怕只启用过一次 =3，如果没有清理就重启，undo log 会失效，导致回滚无法执行。
