据我所知，锁兼容性矩阵中的s和x都是记录锁，对吗？
这是正确的。不正确的假设是您可以直接比较表锁和记录锁，文档可能没有完全阐明这一点，“这些规则可以通过下面的锁类型兼容性矩阵方便地总结”部分可能有点误导，因为它并没有涵盖所有的信息（即关于 S / X -表锁和记录锁）。
从技术上讲，该矩阵定义了检查某个对象的锁时的结果，例如每当mysql试图向某个对象添加锁时。如果你想得到一个 S 锁在table上，它会与 IX 锁上那张table。
如果一个记录可以有一个意图锁，那么它也会在那里发生冲突。仅仅因为一个可锁定的对象不使用意图锁，就不会改变（一般的）兼容性矩阵。
从技术上讲，锁的内部数据类型对于记录和表是相同的，只是从不为记录设置意图锁。记录锁实际上永远不会与表锁比较（因为它们是两个不同的对象），记录锁干扰表锁的唯一原因是锁定协议（需要表和记录上都有锁才能锁定记录）。
所以要锁定记录，通常需要一个不同的表锁。兼容性矩阵是相同的，但是表的值可以而且通常会与记录的值不同。
所以
因此，意图锁不会阻止除完整表请求以外的任何请求（例如，锁表。。。写入）。
是正确的，因为只有完整表请求需要与现有意图锁冲突的锁，并且记录不使用意图锁。但重复一下：您仍然需要比较两种不同的锁。一 S -记录上的锁不能与表上的锁冲突，因为这两个对象永远不会被比较。
这本手册是混合表和记录锁一点。它实际上定义了 IS 以及 IX 作为：
意向共享（is）：事务t打算在表t中的各个行上设置s锁。
intention exclusive（ix）：事务t打算在这些行上设置x个锁。
如果你想的话， IS 以及 IX 在某种程度上，可以将矩阵中的属性解释为行的属性（从技术上讲它们不是），而将它们读取为表上的锁（因为它只能为表设置，但它是一个不同的锁）。但是矩阵仍然只描述了比较记录的情况（手册可能没有足够的说明），并且它没有包含任何与 S 或者 X table锁。
总结一下：您不需要“在上面的锁兼容性矩阵中解释ix与s锁的冲突”，因为它根本不包括这种情况。