MySQL 8.0 升级后性能骤降

客户将线上 MySQL 集群从 5.7.29 升级至 8.0.25 后，出现了极为反常的性能问题：业务请求接入后 1 分钟内慢查询激增，SQL 队列持续堆积。诡异的是，服务器监控显示系统负载、CPU 使用率、磁盘 IO 等硬件指标均处于低峰状态，这意味着硬件资源并非瓶颈。经过 1 小时的持续卡顿，直到 DBA 为某核心业务表添加索引后，系统才恢复正常。

二、技术溯源：锁监控机制的底层变革

（一）视图定义的代际差异

深入分析发现，问题根源在于 MySQL 8.0 对锁监控视图的底层实现重构。对比两个版本的sys.innodb_lock_waits视图定义可见：

• 5.7 版本：基于information_schema.innodb_lock_waits等 3 个基表，仅记录阻塞其他事务的锁
• 8.0 版本：转向performance_schema.data_locks等新基表，记录所有事务持有的锁

-- MySQL 5.7简化视图定义
CREATE VIEW sys.innodb_lock_waits AS 
SELECT ... FROM information_schema.innodb_lock_waits w 
JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id 
-- 省略其他JOIN条件
ORDER BY r.trx_wait_started

-- MySQL 8.0简化视图定义
CREATE VIEW sys.innodb_lock_waits (...) AS 
SELECT ... FROM performance_schema.data_lock_waits w 
JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID 
-- 省略其他JOIN条件
ORDER BY r.trx_wait_started

 

（二）锁表行为的核心差异

performance_schema.data_locks表与旧版innodb_locks表的本质区别在于：

• 5.7 的 innodb_locks：仅记录 "阻塞其他事务的锁"，数据量通常较小
• 8.0 的 data_locks：记录 "所有事务持有的锁"，数据量可能呈指数级增长

这种变化导致当存在大锁操作时，data_locks表会积累海量记录。例如某业务 SQL 对 300 万条记录加锁时，该表会瞬间产生 300 万条锁记录。

（三）互斥量竞争的连锁反应

MySQL 线程读取data_locks表时会持有trx_sys->mutex全局互斥量，直至完成全表扫描。该互斥量用于保护全局事务链表，所有 InnoDB 事务在启动时都需要获取它。当data_locks表数据量庞大时：

1. 读表操作耗时剧增，互斥量持有时间延长
2. 新事务无法加入全局链表，导致 SQL 排队
3. 监控脚本与业务 SQL 形成资源竞争恶性循环

三、实证测试：锁表行为的版本对比

（一）测试环境准备

在 5.7 与 8.0 环境中创建相同表结构：

 

CREATE TABLE `t4` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `e1` enum('长春','沈阳',...) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

 

（二）5.7 版本锁机制验证

1. 在 session1 中执行全表锁定：

begin;
select * from test.t1 for update;

 

2. session2 尝试锁定部分记录时被阻塞
3. 查询innodb_locks表仅返回 2 条记录，仅包含阻塞关系相关锁

（三）8.0 版本锁机制验证

1. 相同全表锁定操作在 session1 执行
2. session2 同样出现阻塞
3. 查询data_locks表返回 11 条记录，包含事务持有的所有 10 条锁及 1 条等待锁

四、解决方案与优化建议

（一）紧急修复措施

为触发大锁的业务 SQL 对应表添加合适索引，避免全表扫描加锁。案例中添加索引后，单次 SQL 的加锁记录从 300 万条降至数十条，彻底消除了互斥量长时间占用问题。

（二）长效优化策略

1. 监控脚本优化：将高频执行的锁监控脚本替换为查询performance_schema.data_lock_waits，该表仅记录锁等待关系，数据量远小于data_locks
2. 锁行为审计：定期分析业务 SQL 的加锁范围，通过索引优化、分批次操作等方式减少锁持有数量
3. 版本适配调整：在 8.0 环境中，对涉及锁监控的应用代码进行适配，避免直接查询data_locks表

五、技术启示：版本升级中的隐性陷阱

本次案例揭示了数据库升级中容易被忽视的底层机制变化：

1. 元数据存储位置迁移：5.7 到 8.0 中，部分核心元数据从information_schema迁移至performance_schema，访问行为随之改变
2. 锁监控粒度变化：8.0 增强了锁监控的完整性，但也带来了性能代价，需根据业务场景权衡
3. 互斥资源保护：trx_sys->mutex作为 InnoDB 核心互斥量，其竞争状况对系统并发能力影响深远

对于计划升级到 MySQL 8.0 的用户，建议在预发环境中重点测试以下场景：

• 高频锁监控操作的性能影响
• 大事务场景下的锁表数据量
• 核心互斥量的竞争情况

通过全面的兼容性测试和针对性优化，才能充分释放 MySQL 8.0 的新特性优势，避免陷入隐性的性能陷阱。