行锁 : 对表中行记录的锁
- MySQL 的行锁 : 由各个引擎自己实现
- MyISAM 不支持行锁
- InnoDB 支持行锁
两阶段锁协议 : 行锁是在需要时才加上，要等到事务结束才释放
例子 : id 是表 t 的主键的
- B 的 update 会阻塞，直到 A 执行 commit 后，B 才能继续执行
事务中要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放
例子 : 电影票交易
- 考虑到影院账户的余额最容易冲突的，事务中的操作顺序 : 3 -> 1 -> 2
- 从顾客 A 账户余额中扣除电影票价 : update
- 给影院 B 的账户余额增加这张电影票价 : update
- 记录一条交易日志 : insert
死锁
死锁 : 不同线程出现循环资源依赖，涉及的线程都等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态
死锁例子 :
- A 等待B 释放 id=2 行锁，而 B 等待 A 释放 id=1 行锁
- A 和 B 都互相等待对方的资源释放，就进入了死锁状态
死锁策略 :
- 设置等待超时 :
innodb_lock_wait_timeout(默认 : 50s , 不易调整) - 开启死锁检测，当出现死锁，主动回滚死锁中的某个事务，让其他
事务继续执行 :innodb_deadlock_detect = on2
主动死锁检测 : 能快速发现并进行处理，但要耗费 CPU
死锁检测耗费 CPU 解决方案 :
- 确保该业务一定不会出现死锁，能临时关掉死锁检测 (风险)
- 出现死锁，就回滚，通过业务重试就没问题，对业务无损
- 关掉死锁检测 : 会出现大量的超时，对业务有损
- 控制并发度 : 并发控制在同行同时最多只有 10 个线程在更新，死锁检测的成本很低
- 考虑在中间件实现
- 修改 MySQL 源码 : 对相同行的更新，在进入引擎之前排队 , 避免大量的死锁检测
- 将一行改成逻辑多行来减少锁冲突
- 将影院的账户总额拆分成 10 个记录的值的总和。每次修改账户就随机选其中一条记录修改
- 每次冲突概率变成 1/10，减少锁等待个数，减少死锁检测的 CPU 消耗
- 该方案要根据业务逻辑做详细设计，代码要有特殊处理
