长事务会阻塞purge线程，导致版本链过长、CPU开销剧增、查询变慢；其根本原因是ReadView锁住历史版本，使undo log无法清理，需从应用层消除长事务而非依赖OPTIMIZE TABLE等无效操作。
长事务会卡住 purge 线程，导致版本链越积越长
版本链本身不占磁盘空间，但每个历史版本都依赖 undo log 存活；而 undo log 的清理由 purge 线程负责。只要有一个活跃事务（哪怕只是只读）的 ReadView 还“看得到”某行旧版本，purge 就不能删它。
常见错误现象：SHOW ENGINE INNODB STATUS 里 PURGE DONE 滞后、innodb_purge_lag 持续升高、information_schema.INNODB_TRX 中存在运行超 60 秒的事务。
- MySQL 5.6+ 默认
innodb_purge_threads = 4，但若长事务持续存在，purge 实际处于“空转”状态——有任务，却不敢清理 - 应用层在事务里做 HTTP 调用、sleep、文件 IO，是典型诱因；这类事务看似没写数据，但它的
ReadView锁死了所有被它“见过”的行的历史版本 -
innodb_max_purge_lag不是越大越好：设得过高会让 purge 更滞后；设得太低又可能触发延迟插入（innodb_max_purge_lag_delay），反而拖慢写入
undo log 截断失败时，版本链回收直接停摆
innodb_undo_log_truncate = ON 是启用 undo 表空间自动截断的前提，但它只对“空闲”的 undo 段生效。如果某个 undo 段里还存着被长事务引用的版本，即便该段已无新写入，也不会被截断。
使用场景：MySQL 5.7+ 启用了独立 undo 表空间（innodb_undo_tablespaces > 0）后，才真正支持 truncate；否则即使参数开启也无效。
- 检查是否生效：
SELECT COUNT(*) FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE 'undo%' AND FILE_SIZE > 0 - 若
innodb_undo_log_truncate = ON但INFORMATION_SCHEMA.INNODB_METRICS中undo_truncations值长期为 0，说明 purge 被阻塞或 undo 段全被占用 - 不要手动
DROP TABLESPACE或清空 undo 文件——这会导致 crash recovery 失败
SELECT 变慢不是因为磁盘 IO，而是 CPU 白跑
执行计划显示走了索引，EXPLAIN 也没警告，但单条 SELECT 耗时从 1ms 涨到 200ms？大概率是 MVCC 版本链过长触发了高频指针跳转。
每次读一行，InnoDB 都要顺着 roll_pointer 往前遍历 undo log，比对每个版本的 trx_id 和当前事务的 ReadView，直到找到可见版本。这不是 I/O 瓶颈，是纯 CPU 循环开销。
- 热点行被高频更新（如计数器、状态字段），每秒几十次 UPDATE，几小时后版本链就可能达数百层
-
INSERT ... ON DUPLICATE KEY UPDATE比SELECT + UPDATE更安全：前者只生成一个新版本；后者至少生成两个（SELECT 触发快照，UPDATE 再生成） - 监控建议：定期查
information_schema.INNODB_BUFFER_POOL_STATS中DATA_READS和DATA_WRITES比值突降，常伴随高CPU usage但低IO wait
OPTIMIZE TABLE 对版本链完全无效，还可能加重问题
OPTIMIZE TABLE 只拷贝当前可见版本到新表，既不触碰 undo log，也不缩短任何已有行的版本链。后台 undo 仍完整保留，purge 仍卡住，查询照样慢。
更麻烦的是：重建过程会持 SX 锁，阻塞 DML；且全表扫描会把大量冷数据刷进 buffer pool，挤走热点页。
- 误判信号：
OPTIMIZE TABLE后data_length下降 ≠ 版本链变短；那只是“当前可见版本”体积小了 - 真正该盯的是
information_schema.INNODB_METRICS中innodb_purge_trx_weight和innodb_purge_undo_pages是否增长 - 线上环境慎用
OPTIMIZE TABLE：它解决的是碎片和 B+ 树深度问题，和 MVCC 无关；拿它治“慢查询”，等于给发烧病人贴退热贴治阑尾炎
START TRANSACTION 后跟了三次 API 调用，没人意识到它锁死了整个库的版本清理能力。 
