行锁 : 对表中行记录的锁

• MySQL 的行锁 : 由各个引擎自己实现
• MyISAM 不支持行锁
• InnoDB 支持行锁

两阶段锁协议 : 行锁是在需要时才加上，要等到事务结束才释放

例子 : id 是表 t 的主键的

• B 的 update 会阻塞，直到 A 执行 commit 后，B 才能继续执行

事务中要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放

例子 : 电影票交易

• 考虑到影院账户的余额最容易冲突的，事务中的操作顺序 : 3 -> 1 -> 2

1. 从顾客 A 账户余额中扣除电影票价 : update
2. 给影院 B 的账户余额增加这张电影票价 : update
3. 记录一条交易日志 : insert

死锁

死锁 : 不同线程出现循环资源依赖，涉及的线程都等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态

死锁例子 :

• A 等待B 释放 id=2 行锁，而 B 等待 A 释放 id=1 行锁
• A 和 B 都互相等待对方的资源释放，就进入了死锁状态

死锁策略 :

• 设置等待超时 : innodb_lock_wait_timeout (默认 : 50s , 不易调整)
• 开启死锁检测，当出现死锁，主动回滚死锁中的某个事务，让其他
  事务继续执行 : innodb_deadlock_detect = on2

主动死锁检测 : 能快速发现并进行处理，但要耗费 CPU

死锁检测耗费 CPU 解决方案 :

1. 确保该业务一定不会出现死锁，能临时关掉死锁检测 (风险)

• 出现死锁，就回滚，通过业务重试就没问题，对业务无损
• 关掉死锁检测 : 会出现大量的超时，对业务有损

2. 控制并发度 : 并发控制在同行同时最多只有 10 个线程在更新，死锁检测的成本很低

• 考虑在中间件实现
• 修改 MySQL 源码 : 对相同行的更新，在进入引擎之前排队 , 避免大量的死锁检测

3. 将一行改成逻辑多行来减少锁冲突

• 将影院的账户总额拆分成 10 个记录的值的总和。每次修改账户就随机选其中一条记录修改
• 每次冲突概率变成 1/10，减少锁等待个数，减少死锁检测的 CPU 消耗
• 该方案要根据业务逻辑做详细设计，代码要有特殊处理