事务被自动回滚大概率不是内存溢出直接导致，而是应用捕获out of sort memory等错误后主动回滚，或oom killer杀掉mysqld进程致事务丢失；需查错误日志确认具体原因，优先优化索引而非盲目调大sort_buffer_size。
事务被自动回滚，真是内存溢出吗？
大概率不是。MySQL 本身不会因为“内存不足”直接触发 ROLLBACK；所谓“自动回滚”，通常是上层应用（如 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 就废了，回滚直接失效。
