行锁的S锁和X锁
Innodb实施标准的行级锁，其中有两种类型的锁：
Shared lock即共享锁，S锁。如果事务对数据行r持有S锁，那么允许其它事务对数据行r持有S锁，但不允许其它事务对数据行持有X锁。
Exclusive lock即排它锁，X锁。如果事务T1对数据行r持有X锁，那么就不允许其它事务对数据行持有S锁或X锁，除非等到T1释放r上的X锁
意向锁（Intention lock）
Innodb支持多粒度锁，即允许记录锁（record locks）和表锁共存（InnoDB supports multiple granularity locking which permits coexistence of record locks and locks on entire tables）。为了在多个粒度级别上实现锁定，innodb引进了意向锁。有两种意向锁：
Intention shared（IS）：意向共享锁，表示事务T将要对表中数据行加S锁，而先在表级别上加的就是IS锁；
Intention exclusive（IX）：意向排它锁，表示事务T将要对表中数据行加X锁，而先在表级别上加的就是IX锁；
意图锁是表锁，它指示事务稍后将在表数据行上加何种类型的锁。IS锁表示事务稍后会在数据行上加S锁，IX锁表示事务稍后会在数据行上加X锁。常见的，像“select … lock in share mode”语句会加IS锁，“select … for update”语句会加IX锁。
所以，引入意图锁的目的就是为了支持多粒度锁定，并能通过意图锁显示事务锁定了表中的某些行，或者将要锁定表中的某些行。
意图锁的协议如下：
一个事务要想获得行上的S锁，必须先获取该表上的IS或者更强的锁；
一个事务要想获得行上的X锁，必须先获取该表上的IX锁。
四种锁之间的兼容性如下：
如果事务请求的锁与现有锁兼容，则授予该事务锁；但如果与现有锁冲突，则不授予该事务锁，事务需要等待现有锁被释放后才能获取锁。
说明：
个人认为，上面的S和X锁是表级别的S和X锁。但之前和朋友讨论，说没有表级别的S和X锁，只有行级别的S和X锁，并上面指的是行级别的S和X锁。后来发现在姜承尧的innodb内幕这本书中，也提到上面指的是行级别的S和X锁。
因此有些疑惑的就是：锁的粒度不同，如何讨论兼容性？更何况意图锁引入的目的就是为了支持mysql的多粒度锁定。
死锁
死锁演示：
会话1上开启事务T1:
mysql> start transaction;
mysql> select * from ecs_payment where pay_id=2332 lock in share mode;
+--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+
| pay_id | pay_code | pay_name | pay_fee | pay_desc | pay_order | pay_config | enabled | is_cod | is_online |
+--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+
| 2332 | 83 | ^{} | 4090.99 | bwlw]^k | 13 | lb^wkw] | 1 | 0 | 0 |
+--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+
AI 代码解读
会话2上开启事务T2:
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update ecs_payment set pay_name='tiatiao' where pay_id=2332; --被卡住
AI 代码解读
会话1的事务T1再执行操作：
mysql> delete from ecs_payment where pay_id=2332;
Query OK, 1 row affected (0.00 sec)
AI 代码解读
这时再看会话2的事务T2，会输出如下信息：
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
AI 代码解读
发生死锁的四个必要条件：
互斥条件
不可剥夺
请求与保持
循环等待
注意：
如果InnoDB监视器输出的最新检测到的死锁部分包含如下输出信息：
TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION
AI 代码解读
这表明锁等待列表上的事务数量已经达到了200个的限制，超过200个事务的等待列表被视为死锁，这个数量限制和参数LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK有关
