undo log回放是串行且不可跳过的物理操作：回滚需逐条重放undo记录，走磁盘随机I/O、单线程执行，耗时取决于修改行数、undo大小及磁盘性能；SSD上单独部署undo表空间可提速3–5倍。
undo log 回放是串行且不可跳过的物理操作
执行 DML 时，InnoDB 只需把变更写入 buffer pool 和 redo log，大部分是内存操作，还能批量合并；而回滚必须逐条重放 undo log，每条都要定位数据页、加锁、恢复旧值、清理锁结构、更新页状态——全部走磁盘随机 I/O 路径，且完全单线程执行。即使你 KILL 了线程，TRX_STATE 仍为 'ROLLING BACK'，说明回滚逻辑还在跑。
回滚耗时和修改行数、undo log 大小强相关
回滚不是“撤销 SQL”，而是反向应用 undo 记录。常见现象：INFORMATION_SCHEMA.INNODB_TRX 中 TRX_ROWS_MODIFIED 很大（比如 500 万），但回滚进度几乎不动。这是因为：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 每行 undo 记录可能跨多个 page，触发大量磁盘寻道
- undo 表空间若在机械盘上，I/O 延迟直接拉爆耗时
- 如果事务中途还做了二级索引更新，回滚时要同步修正所有二级索引项，开销翻倍
没有“部分回滚中止”机制，也没有安全绕过方式
InnoDB 没有类似 Oracle 的 ALTER SYSTEM KILL SESSION ... IMMEDIATE，也不支持跳过某段 undo。试图用 innodb_force_recovery > 0 启动只是让实例能读，不能跳过回滚；删 ibdata1 或 undo_001 是彻底丢数据，不是“加速回滚”。真正能影响回滚时间的，只有磁盘 I/O 能力和 undo 表空间位置——这点容易被忽略：把 undo 表空间单独放在 SSD 上，比混在系统盘里快 3–5 倍。
