大量delete后查询变慢的主因是mvcc版本链膨胀，即未purge的undo log堆积导致快照读需遍历大量已删版本，引发cpu飙升和延迟上升。
大量 DELETE 后查询变慢，大概率不是磁盘或索引问题，而是 MVCC 版本链被撑爆了 —— 即便你只删不查，后续所有快照读（普通 SELECT）都得在 undo log 里“翻旧账”，链越长，CPU 越累，延迟越稳。
为什么 DELETE 会拉长 MVCC 版本链
InnoDB 的 DELETE 实际是“标记删除”：行记录的 trx_id 被设为当前事务 ID，并把旧版本写入 undo log，形成一条向后的版本链（通过 rollptr 指向）。只要还有活跃事务依赖这个旧快照，这条链就无法回收。
常见诱因包括：
- 长时间未提交的事务（比如应用端开启事务后卡住、忘记
COMMIT或ROLLBACK） - 设置了
autocommit = 0但没显式控制事务边界 - 监控类或报表类查询用了
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ并长期保持连接
一旦有这类事务存在，所有新事务生成的 READ VIEW 都必须保留它启动时能看到的所有版本 —— 包括那些已被 DELETE 标记、但尚未 purge 的行。结果就是：一个简单 SELECT COUNT(*) FROM t 可能要遍历数万条已删除但未清理的版本。
SHOW ENGINE INNODB STATUS 里怎么看版本链压力
执行该命令后，在 TRANSACTIONS 和 INSERT BUFFER AND ADAPTIVE HASH INDEX 之间找 History list length 这一行：
---TRANSACTION 421589312, not started History list length 124876
这个数字代表当前未 purge 的 undo log 条目总数。线上环境超过 10000 就值得警惕；若持续 > 100000，基本可断定 purge 线程追不上写入速度。
注意：History list length 不是实时下降的 —— 它只在 purge 线程真正清理完一批 undo 后才减小，且受 innodb_purge_batch_size 和 innodb_max_purge_lag 控制。
如何快速验证是不是版本链导致慢查
用一个最小化、无干扰的只读事务去复现慢查询，同时观察是否伴随高 CPU 和低 I/O：
- 开新连接，
SET autocommit = 1，再执行慢 SQL，排除客户端事务残留影响 - 对比
EXPLAIN FORMAT=JSON中的rows_examined和实际返回行数：若前者远大于后者（比如查 10 行却扫描 50 万），说明在过滤大量已删除版本 - 查
information_schema.INNODB_TRX，重点关注TRX_STARTED时间过久（> 10 分钟）的事务 - 运行
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%SELECT%'，看是否有线程状态为executing但PROCESSLIST_TIME持续增长 —— 这是典型版本链遍历卡顿表现
临时缓解和长期规避的关键动作
这不是加索引或调缓存能解决的问题，核心是让版本链“瘦下来”：
- 立刻杀掉异常长事务：
KILL [trx_mysql_thread_id]（从INNODB_TRX表中取） - 强制触发 purge：
SET GLOBAL innodb_max_purge_lag = 0（慎用，可能短暂影响写入性能） - 确认
innodb_purge_threads >= 1（5.7 默认为 1，但某些定制版可能被改） - 业务层杜绝隐式长事务：ORM 框架如 MyBatis 的
@Transactional必须明确超时时间；HTTP 接口内避免跨 DB 操作+远程调用混合在同一个事务里 - 对高频删除表，考虑改用
TRUNCATE TABLE（注意它不走 MVCC，不可回滚，且会重置 AUTO_INCREMENT）
版本链膨胀是个“静默雪球”：它不报错、不锁表、甚至不占磁盘空间（undo log 在 ibdata 或独立表空间里，但 purge 滞后会导致空间无法复用），最容易被误判为“数据库老化”或“硬件瓶颈”。盯紧 History list length 和活跃事务生命周期，比优化单条 SQL 更治本。
