innodb行锁等待显著下降，但仅在热点行更新密集时明显；8.0通过拆分lock_sys锁、writeset并行复制和cost model优化提升性能，需配合analyze table及正确配置。
innodb_row_lock_waits 降得明显，但只在热点行更新密集时才看得见——不是所有场景都变快，别指望“升级就提速”。
锁系统重构缓解高并发争用
5.7 的 lock_sys->mutex 是单点瓶颈，压测时经常出现在 SHOW ENGINE INNODB STATUS 的等待列表顶部；8.0 拆成多个细粒度锁（rec_hash、prdt_hash、wait_mutex），把锁分配器本身的开销压下来了。
- 实测 1000 QPS 主键更新，
innodb_row_lock_time_avg下降约 35%，innodb_row_lock_waits增长更平缓 -
innodb_sync_array_size控制哈希分片数，默认值不够时会出现rec_hash负载倾斜，可适当调大（比如从 256 改到 512） - 旧监控脚本若靠正则解析
SHOW ENGINE INNODB STATUS中的LOCK WAIT段落，大概率失效——8.0 输出格式已重排
WRITESET 让主从复制不卡在时间缝隙里
5.7 的并行复制靠 last_committed 凑组，事务间隔稍大就退化为串行；8.0 的 WRITESET 直接算行级哈希交集，哪怕两个事务相隔几分钟、改的是不同表，只要没碰同一行，就能并行回放。
- 主库必须设：
binlog_transaction_dependency_tracking = WRITESET - 从库必须设：
slave_parallel_type = LOGICAL_CLOCK（注意不是WRITESET） -
transaction_write_set_extraction = XXHASH64建议保持默认，乱改可能引发校验失败 - 低峰期或定时任务单条更新的场景，5.7 经常卡在
Waiting for an event from Coordinator，8.0 基本不受影响
Cost Model 让索引选择更“算账”，但依赖统计信息
5.7 看到索引就走，8.0 会估算 I/O + CPU 总成本再选——好处是复杂查询更可能避开全表扫描，坏处是统计信息陈旧时反而选错。
- 升级后第一件事：对大表执行
ANALYZE TABLE，否则EXPLAIN FORMAT=TREE显示的 cost 值全是瞎估 -
SELECT @@optimizer_switch LIKE '%cost_model=on%'确认是否启用 - 函数索引（如
UPPER(name)）和降序索引（a DESC, b ASC）也走这套逻辑，但匹配是字面级精确：多一个空格、大小写不一致，就视而不见
真正容易被忽略的点不在代码里，在绑定时机
函数索引生效与否，取决于 SQL 解析阶段是否字面匹配；降序索引能否免 Using filesort，取决于 ORDER BY 方向与定义是否严丝合缝。这些都不是运行时推导出来的，而是 parser 那一刻就定死的——查 EXPLAIN 的 key 字段，看到的是虚拟列名（如 func_001），不是你写的函数表达式。
