理解 MySQL 行锁：两阶段锁协议与热点更新优化
一、 两阶段锁协议 (2PL)
理解行锁的第一步是掌握两阶段锁协议。在 InnoDB 事务中，行锁的生命周期遵循以下规则：
按需加锁：行锁是在事务执行过程中，需要访问具体行记录时才加上的 。
统一释放：事务持有的所有行锁并不会在 SQL 执行完后立即释放，而必须等到事务提交（Commit）或回滚时才统一释放 。
业务设计启示
这一机制告诉我们：如果一个事务需要锁定多个行，应该将最可能造成锁冲突、最影响并发度的锁尽量往后放。
案例：电影票交易业务
假设一笔交易包含扣除顾客余额、增加影院余额、记录日志三个操作 。由于多个事务可能同时更新同一个影院的余额（热点行），最佳的执行顺序是：
- 记录交易日志（Insert）
- 扣除顾客余额（Update）
- 增加影院余额（Update）—— 放在最后，以减少该热点行锁定的时长 。
二、 死锁及其处理策略
当两个或多个事务出现循环资源依赖，互相等待对方释放资源时，就会进入死锁（Deadlock）状态。
InnoDB 提供了两种策略来应对死锁：
等待超时：事务持续等待直到达到
innodb_lock_wait_timeout设置的时间（默认 50s）后报错退出 。死锁检测：开启
innodb_deadlock_detect（默认开启），系统主动发现死锁链条并回滚其中一个事务，让其他事务继续 。
三、 热点行更新的性能陷阱
虽然死锁检测能快速解开死锁，但在高并发更新同一行的场景下，它会带来巨大的 CPU 开销。
每当一个新请求被阻塞，系统都要检查该请求的加入是否会导致死锁。对于nnn个并发线程，死锁检测的时间复杂度是O(n)O(n)O(n)。当并发数达到 1000 时，检测量级可达百万次，这会导致 CPU 利用率接近 100%，但实际执行的事务却寥寥无几 。
四、 优化热点更新的三个思路
针对这类由死锁检测引起的 CPU 瓶颈，可以从以下维度进行优化：
临时关闭死锁检测：如果能确保业务逻辑本身不会产生死锁，可以关掉检测 。但这可能导致大量事务堆积并触发超时，对业务有损 。
服务端并发控制：在进入引擎层之前进行排队（如在中间件或修改数据库内核），限制同一行同时更新的并发数，从而降低死锁检测的成本 。
数据拆分（逻辑多行）：将热点行拆分为多行记录 。例如，将影院账户余额分散到 10 条记录中，总余额为各行之和 。更新时随机选择一行进行操作，可将冲突概率降低到原来的1/101/101/10，显著减少锁等待和 CPU 消耗 。