mysql中存在四个队列，分别存储当前获取读锁的信息、当前获取写锁的信息、等待读锁的信息、等待写锁的信息：
| 队列 | 含义 |
| current read-lock queue | 当前获取读锁队列 |
| current write-lock queue | 当前获取写锁队列 |
| pending read-lock queue | 等待读锁队列 |
| pending write-lock queue | 等待写锁队列 |
读锁的获取条件
1. 当前资源没有被写锁被占用。
2. 当前没有 等待写锁队列 中没有高优先级的写锁等待。
如果满足上述条件，可直接获取到读锁，若有一个无法满足，则进入PRQ
写锁的获取条件
1. 当前资源没有被写锁占用。
2. PWQ没有等待写锁
3. RQ没有读锁
锁，就是一台电脑。
现有写锁时，排斥任何锁众所周知，写锁排斥一切，为了数据安全，和数据读取的准确性，写锁排斥其他一切形式的锁。
写锁就如同你正在玩【写】电脑游戏，别人肯定不能同时玩【写】这台电脑，想玩【意向写】也玩不了。同时，玩游戏的人还比较自私，怕输了丢人，不让别人一旁观看【读】，想看【意向读】也不让看。
现有读锁时，排斥一切形式的写锁，包括意向写锁有读锁时，不能再加写锁。但是可以允许并发读。意向锁虽然是一种意向，不是真正意义上的锁，但是也存在着读写排斥的道理。
读锁就如同你正在用电脑看【读】电影，别人肯定不能同时玩【写】电脑游戏，想玩【意向写】也玩不了。同时，看电影的人懂得分享，邀请别人一同观看【读】，想看【意向读】也让看。
现有意向写锁时，排斥一切实体锁
意向写锁，表示我想要写，下一步就是真的获取到了写锁，所以会排斥实体读写锁，但是意向毕竟是意向，还没有实际意义获取到，你不能不允许别人也臆想。
意向写锁就如同你排队等电脑玩【写】游戏，下一个就到你了，排队这么久，别人来玩【写】游戏你肯定不答应，别人来看【读】电影你肯定也不答应。有人许愿：”但愿下一个到我玩游戏了【意向写】“，你说：”不出意外的话马上到我了，你继续YY吧，允许你想想“。有人许愿：”但愿下一个到我看电影了【意向读】“，你说：”不出意外的话马上到我了，你继续YY吧，允许你想想“。
现有意向读锁时，排斥实体写锁意向写锁是一种意向，打算读，下一步就是获取读锁。这就会排斥实际的写锁。前面说到允许并发读，所以不会排斥读锁。意向也毕竟是意向，不能不允许别人臆想。
意向读锁就如同你排队等看【写】电影，下一个就到你了，别人来玩【写】游戏你肯定不答应，别人一起来看【读】电影你欣然答应（毕竟现在还没到我，何况他有可能邀请我一起看）。有人许愿：”但愿下一个到我玩游戏了【意向写】“，你说：”不出意外的话马上到我了，你继续YY吧，允许你想想“。有人许愿：”但愿下一个到我看电影了【意向读】“，你说：”不出意外的话马上到我了，你继续许愿吧，没准还能一起看“。
Update使用where条件时，命中索引，锁定一行，行写锁使用
Update使用where条件时，没有命中索引，锁表 update使用where条件时，命中索引，但是使用范围，锁定间隙 update使用where条件，部分条件使用索引，锁定该索引覆盖的所有数据行，数据行锁 两个事务均操作两张表，先后获取不同的锁，导致死锁
