首先看下mysql官方的概念和描述
InnoDB 支持多粒度锁（multiple granularity locking），它允许行级锁与表级锁共存，而意向锁就是其中的一种表锁。
共享锁（ shared lock, S ）锁允许持有锁读取行的事务。加锁时将自己和子节点全加S锁，父节点直到表头全加IS锁
排他锁（ exclusive lock， X ）锁允许持有锁修改行的事务。 加锁时将自己和子节点全加X锁，父节点直到表头全加IX锁
意向共享锁（intention shared lock, IS）：事务有意向对表中的某些行加共享锁（S锁）
意向排他锁（intention exclusive lock, IX）：事务有意向对表中的某些行加排他锁（X锁）
然后mysql给出了一下的冲突矩阵
不过，查阅的一些资料后，我们可以将数据库的树状结构比喻成高速公路，其中S锁表示道路清洁（使用），X锁表示道路维修（封闭）。IS表示道路清洁提示牌，IX表示道路维修警示牌。类比于mysql官方定义，我们约定：
1、当前节点发生道路维修时，当前节点及其子节点全部处于封闭状态（X），其父节点直至表头全部处于维修警示状态（IX）
2、当前节点发生道路清洁时，当前节点及其子节点全部处于使用状态（S），其父节点直至表头全部处于清洁提示状态（IS）
通过上图分析如下场景：简称X（维修）S（清洁）IS
1. 假设节点5进行维修，5及其子节点（4、5、6）进入维修X状态，由于维修状态其他什么也做不了，所以（4、5、6）不接受（X维修、IX警示、S清洁、IS提示）相关工作。对应的（X与X、IX、S、IS冲突）
2. 紧接着1来说，同时父节点（3、7）进入IX警示状态，因为（3）清洁S状态会将（1、2、4、5、6）全标记为S状态，其中的（4、5、6）会和维修X冲突，所以（3、7）会和（X维修、S清洁）冲突。如果此时（2）需要进入维修X或者清洁S的话，他同样也会标记（3、7）进入（IX警示或者IS提示）由于2这边和5是两条路，所以在（3、7）这里再加警示（IX）或者提示（IS）都是不冲突的，所以（3、7）接受（IX警示、IS提示）。对应的（IX与X、S冲突，与IX、IS不冲突）
3.假设节点5进行清洁，5及其子节点（4、5、6）进入清洁S状态，将不接受（X维修、IX警示），因为如果出现警示（IX）则代表（5、6或者更底层存在X），而S的底层都是S，X与所有互斥。对应的（S与X或者IX冲突，与S或者IS不冲突）
4.同时父节点（3、7）进入IS提示状态，由于提示IS状态下可以允许另外一条更底层的的X放置的IX状态并行存在，如（8|9|10处于维修X状态）导致7标记为IX状态。对应的（IS仅与X冲突，与IX、S、IS不冲突）
最后，不难得出结论：
再看看其他其他文章对意向锁的总结：
1、InnoDB 支持多粒度锁，特定场景下，行级锁可以与表级锁共存。
2、意向锁之间互不排斥，但除了 IS 与 S 兼容外，意向锁会与 共享锁 / 排他锁 互斥。
3、IX，IS是表级锁，不会和行级的X，S锁发生冲突。只会和表级的X，S发生冲突。
4、意向锁在保证并发性的前提下，实现了行锁和表锁共存且满足事务隔离性的要求。
将表级锁理解成上图中任意节点添加意向锁直至根节点（7）时，这个意向锁锁了表的一部分（例子使用二叉树举例的，实际是具体看B+索引的分布），对于其中第三点，同一节点的行级IX、IS锁也会和当前节点的X、S锁发生冲突。根节点的表级IX、IS锁会和根节点的表级X、S锁发生冲突。第四点是它存在的意义即作用，可以理解表级锁也不是真正的锁全表，而是锁了发生读或写的那条索引链路上的相关节点。
