直接查看SHOW ENGINE INNODB STATUS\G中TRANSACTIONS部分，若发现大量事务状态为LOCK WAIT且集中阻塞在同一表的同一二级索引（如idx_user_id），同时top显示CPU高但慢查询日志无显著慢SQL，即可确认为行锁争用；进一步通过performance_schema.data_lock_waits（MySQL 8.0.24+）或sys.innodb_lock_waits查LOCK_DATA定位热点行值。
MySQL CPU飙升时，怎么快速确认是行锁争用？
直接看 SHOW ENGINE INNODB STATUS\G 里的 TRANSACTIONS 部分，重点找 lock struct(s) 数量多、且多个事务卡在同一个 TABLE + INDEX 上的记录。如果看到大量事务状态为 LOCK WAIT，并反复指向同一张表的同一二级索引（比如 idx_user_id），基本就是热点行锁争用。此时 top 显示 mysqld 进程 CPU 高，但慢查询日志里却没多少慢 SQL——因为不是执行慢，是等锁久。
如何定位具体哪几行被高频争抢？
靠 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 关联查还不够细；更有效的是开启 performance_schema 的锁监控：
- 确保已启用：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/innoDB/row_lock' - 查当前锁等待链：
SELECT * FROM performance_schema.data_lock_waits（MySQL 8.0.24+）或回退到sys.innodb_lock_waits视图 - 关键字段是
LOCK_DATA：它会显示被锁住的具体主键值（如12345）或唯一索引值（如'u_789@example.com'），这就是热点行
注意：LOCK_DATA 在非唯一索引上可能显示范围（如 min_key: 100, max_key: 200），说明争用发生在间隙锁范围，不单是一行。
确认热点行后，为什么不能直接加索引或拆分表？
加索引可能让原本走全表扫描的 UPDATE 变成索引查找，反而加剧单个索引页的锁竞争；而盲目分表（如按 user_id 拆）若业务逻辑仍需跨分片聚合，会引入分布式事务或最终一致性难题。真正有效的扩容路径取决于写入模式：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果是「高并发更新同一账户余额」：优先改用乐观锁（
WHERE version = ? AND balance > ?）+ 重试，避免长事务持锁 - 如果是「秒杀扣库存」：把单行
stock拆成多行（如stock_shard_0到stock_shard_7），应用层哈希取模分散写入 - 如果是「日志类高频 INSERT」：确认是否误用了
INSERT ... ON DUPLICATE KEY UPDATE——它会对冲突键加 next-key lock，换成普通INSERT IGNORE或异步写入队列更稳妥
ALTER TABLE 扩容期间锁表怎么办？
MySQL 5.6+ 的 ALGORITHM=INPLACE 并非完全无锁：对二级索引增删、字段长度扩展等操作，仍会在 DML 高峰期引发元数据锁（MDL）等待，间接推高 CPU。安全做法是：
- 用
pt-online-schema-change工具，它通过触发器双写保障在线性，但要求主键存在且无外键 - 若用
gh-ost，注意它依赖 binlog 解析，在 GTID 关闭或从库延迟大时可能卡住，上线前务必在备库压测 - 禁止在业务高峰期执行任何 DDL；可通过
SELECT * FROM performance_schema.metadata_locks实时观察 MDL 等待情况
最常被忽略的一点：即使锁粒度降到行级，InnoDB 的 row lock 本质仍是 latch（内存自旋锁）竞争，当单个 page 内热点行过多，CPU 会花大量时间在 spin-wait 上——这时加机器不如先减少单页数据密度，比如调大 innodb_page_size（需重建实例）或调整业务批量写入大小。
