长事务导致MVCC版本链过长会拖慢SELECT，因需CPU遍历undo链判断可见性；OPTIMIZE TABLE仅拷贝当前可见版本，不清理undo或缩短版本链，对其完全无效。
长事务导致的 MVCC 版本链过长，本身不会直接让 OPTIMIZE TABLE 变快或变慢；但它是查询变慢的深层诱因之一，而 OPTIMIZE TABLE 对它完全无效——这点必须先说清。
为什么版本链过长会让 SELECT 变慢
InnoDB 每次读取一行时，要根据当前事务的 ReadView 去判断该行哪个版本可见。如果某行被反复更新了上百次，它的 DB_TRX_ID 链就会很长，引擎就得顺着 DB_ROLL_PTR 一路回溯 undo log，直到找到一个满足可见性条件的版本。
- 这不是磁盘 I/O 问题，而是 CPU 循环遍历链表的开销，尤其在高并发、高更新频率的场景下会被放大
- 即使只查单行，也可能触发数十次指针跳转；范围扫描时，每一行都可能重复这个过程
-
EXPLAIN看不出这个问题——执行计划仍是“用索引”，但实际执行时间远超预期
OPTIMIZE TABLE 对 MVCC 版本链毫无作用
OPTIMIZE TABLE 的本质是重建表：创建新空表 → 按主键顺序拷贝**当前可见版本**的数据 → 替换原表。它不清理 undo log，也不缩短任何已有行的版本链。
- undo log 的清理由 purge 线程异步完成，前提是旧事务已全部提交或回滚
- 如果存在一个运行了 3 天的未提交事务，所有被它修改过的行，其历史版本都会被保留，
OPTIMIZE TABLE拷过去的新表里，这些行依然只有最新可见版本，但 undo 链本身仍在后台活着 - 执行
OPTIMIZE TABLE后，information_schema.INNODB_METRICS中的innodb_row_lock_waits或innodb_buffer_pool_read_requests不会因此下降
真正该做的三件事
解决版本链过长，核心是缩短活跃事务生命周期、加速 purge，并避免无谓的多版本生成：
- 查出长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60; - 禁止应用层开启事务后长期不提交（比如在事务里做 HTTP 调用、文件读写）
- 确认
innodb_purge_threads≥ 1（MySQL 5.6+ 默认为 4），并观察SHOW ENGINE INNODB STATUS中的 PURGE DONE 是否滞后 - 对频繁更新的热点行，考虑用
INSERT ... ON DUPLICATE KEY UPDATE替代先SELECT再UPDATE，减少不必要的版本生成
版本链不是碎片，也不是磁盘文件膨胀——它是内存+undo log 的协同状态。OPTIMIZE TABLE 解决不了它，强行执行反而会因全表拷贝引发锁和 I/O 尖峰。盯住事务行为，比优化表结构更关键。
