回滚卡在“rolling back”状态，首要排查磁盘IO与日志空间问题：检查innodb_log_file_size是否过小、df -h确认磁盘是否写满、验证innodb_undo_tablespaces是否耗尽；内存不足非主因，仅会间接加剧IO瓶颈。
回滚卡在“rolling back”状态，先确认是不是内存或磁盘IO问题
MySQL大事务回滚时长时间无响应（比如SHOW ENGINE INNODB STATUS\G里显示ROLLING BACK且undo log entries数很大），不一定是内存不足，更常见的是innodb_log_file_size太小、磁盘写满、或innodb_undo_tablespaces耗尽。内存压力本身不会直接导致回滚失败，但会加剧IO瓶颈——比如buffer pool争抢严重，刷脏页慢，间接拖慢undo应用速度。
验证是否真由内存触发：查free -h看可用内存是否持续低于500MB；用vmstat 1观察si/so（swap in/out）是否频繁；再结合df -h确认innodb_log_group_home_dir所在磁盘是否已满（这才是更常见的根因）。
Swap空间不是解药，而是临时缓冲，加之前必须做三件事
盲目增加Swap可能掩盖真正问题，甚至让回滚更慢（swap IO比磁盘redo写还慢）。只有在确认是短时内存峰值（如并发回滚多个大事务）且无法立刻拆分事务时，才考虑临时扩容：
- 先停掉非关键业务连接，减少buffer pool竞争
- 执行
SET GLOBAL innodb_buffer_pool_size = <略低于物理内存70%的值>;，避免MySQL吃光内存 - 用
swapon --show确认当前swap设备，再用dd if=/dev/zero of=/swapfile bs=1G count=4创建4GB新swap文件，最后mkswap /swapfile && swapon /swapfile
注意：swapon后需改/etc/fstab持久化，否则重启失效；但生产环境不建议长期依赖swap处理回滚——它治标不治本。
真正有效的内存相关优化，是控制undo和buffer pool行为
回滚慢的核心矛盾是undo log读取+行数据页加载+反向更新三者争抢内存与IO。优化方向不是堆内存，而是减少单次回滚负载：
- 调大
innodb_undo_log_truncate（8.0+默认ON），允许自动截断不用的undo段，降低回滚扫描量 - 把
innodb_buffer_pool_instances设为CPU核心数（如8），减少内部锁争用，提升page读取并发度 - 对已知要回滚的大事务，提前执行
KILL <code>trx_mysql_thread_id（从INNODB_TRX查），让InnoDB在后台异步清理，避免阻塞前台连接 - 禁止在事务中做
SLEEP()、SELECT ... INTO OUTFILE等耗内存操作——它们会把buffer pool占满，挤出undo页缓存
别忽略最常被跳过的一步：检查innodb_force_recovery是否误开
如果之前数据库崩溃过，有人手动加过innodb_force_recovery = 1~6启动参数，会导致undo log被跳过解析，回滚直接失败（报Unknown error或静默退出）。查my.cnf或mysqld --print-defaults输出，确认该参数未启用。一旦开启，MySQL会拒绝写入，包括回滚所需的undo应用——此时加再多swap也没用。
真正卡住回滚的，往往不是内存数字本身，而是配置与操作习惯的组合：autocommit开着、DDL混在事务里、buffer pool被大查询打满、又碰上磁盘IO饱和。解决它得一层层剥，而不是一上来就调swap。
