为什么 SELECT ... FOR UPDATE
会卡住其他事务
根本原因不是“锁本身慢”，而是锁等待链形成后，后续事务在
innodb_row_lock_waits计数器里排队，且默认不超时（
innodb_lock_wait_timeout=50秒）。一旦某行被长事务持有
X锁，所有想加锁读/写的并发事务都会阻塞，直到超时或前序事务提交。
实操建议：
用SHOW ENGINE INNODB STATUS\G查看
TRANSACTIONS部分，重点关注
lock struct(s)和
waiting for this lock to be granted行 避免在事务中混用
SELECT ... FOR UPDATE和非必要业务逻辑（比如发 HTTP 请求、调用外部服务） 确认是否真需要行级锁：如果只是防止重复插入，
INSERT ... ON DUPLICATE KEY UPDATE或唯一索引+重试通常更轻量
UPDATE
语句没走索引导致全表锁升级
InnoDB 的行锁是建立在索引之上的。当
UPDATE的
WHERE条件未命中任何索引（或仅命中主键但用了函数/类型隐式转换），InnoDB 会退化为锁住所有扫描过的聚簇索引记录——实际效果接近表级锁，尤其在大表上极易引发大面积阻塞。
实操建议：
执行前必看EXPLAIN输出：
type字段不能是
ALL或
index（全索引扫描也算高风险），
key字段必须显示实际使用的索引名 警惕隐式类型转换：比如
WHERE user_id = '123'（字段是
BIGINT）会导致索引失效；应写成
WHERE user_id = 123对高频更新字段，确保有单独索引或复合索引的最左前缀覆盖，不要依赖联合索引中靠后的列
死锁日志里出现 lock_mode X locks rec but not gap
是什么含义
这表示当前事务持有一个记录锁（
rec），但不包含间隙锁（
gap），常见于唯一索引等值查询（如
WHERE id = 100）。它本身不危险，但若多个事务按不同顺序访问同一组唯一键，就容易触发死锁——因为 InnoDB 按主键顺序加锁，而事务请求顺序不一致。
实操建议：
统一 DML 操作的主键/索引访问顺序：例如批量更新时，ORDER BY id ASC再执行，避免各事务随机跳着锁行 减少事务粒度：把一个大事务拆成多个小事务，降低锁持有时间与交叉概率 应用层捕获
Deadlock found when trying to get lock错误（错误码 1213），实现指数退避重试，而非直接报错
如何定位真实瓶颈：锁等待 vs 磁盘 I/O vs CPU
看到慢查询和锁等待增多，不能直接归因为“锁太多”。先排除硬件和配置层面干扰：比如
innodb_buffer_pool_size过小导致频繁刷脏页，或磁盘 I/O 延迟高（
iostat -x 1查
%util和
await）会拖慢事务提交速度，间接拉长锁持有时间。
实操建议：
查性能视图：SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;找出耗时最长的语句，再结合
sys.schema_table_statistics看其锁等待占比 监控关键指标：
Innodb_row_lock_time_avg> 50ms 说明锁争用已显著；但若
Innodb_buffer_pool_wait_free> 0 或
Pages_read_per_sec持续偏高，优先优化缓存或 I/O 临时降低隔离级别（如从
REPEATABLE READ改为
READ COMMITTED）可减少间隙锁，但需确认业务能否接受不可重复读
锁竞争从来不是孤立问题——它总在事务设计、索引质量、硬件资源和隔离级别之间暴露真实短板。最容易被忽略的是：开发阶段用小数据集测试无锁冲突，上线后数据量增长十倍，原本安全的索引范围查询突然变成全表扫描，锁升级随之而来。
