MySQL中向tableA插入数据为何阻塞无关表tableC的更新？

生产环境中遇到异常场景：
进程A执行以下事务（插入50万条记录，耗时超1分钟）：

set transaction isolation level read committed;
start transaction;
    insert into tableA (f1, f2, f3) select f1, f2, f3 from tempTableB; 
commit;

同时进程B执行单条更新语句：

update tableC set f=f+10 where id=1234;

关键信息：

• tableA与tableC无任何关联，tempTableB是进程A专属临时表
• 插入过程中tableC的更新被阻塞，但读查询正常执行
• 环境细节：托管式MySQL 8.0.21，8核32GB内存+SSD，负载正常，已配置高可用复制，两张表均为InnoDB引擎，无触发器、外键关联

请问该异常的原因是什么？为何无关表的插入会阻塞更新？

原因分析 #

1. InnoDB全局元数据锁（MDL）竞争 #

MySQL执行大DML操作时，哪怕没有显式DDL，也可能因为事务持续时间过长、涉及临时表的复杂查询，导致全局元数据锁持有时间延长。进程A的1分钟级大事务，可能长时间占用全局MDL锁，而进程B的更新操作需要申请表级MDL写锁，就会被阻塞——这是无关表阻塞最常见的场景。

2. Redo Log刷盘阻塞 #

50万条插入会生成海量Redo Log，当Redo Log缓冲区满或者触发刷盘阈值时，InnoDB会强制刷盘到SSD。哪怕整体负载正常，也可能出现瞬间IO队列堆积，导致刷盘耗时增加。而所有InnoDB写操作（包括tableC的更新）都必须先写入Redo Log才能执行，这就会导致更新被阻塞。

3. GTID分配阻塞 #

因为启用了高可用复制的GTID模式，每个事务都要分配唯一GTID。MySQL 8.0.21这个早期版本里，GTID分配的锁机制在大事务场景下存在优化不足，当进程A的大事务持续占用GTID分配资源时，小事务（比如进程B的更新）会卡在等待GTID分配的环节，表现为无关表阻塞。

4. 临时表空间扩展锁竞争 #

虽然tempTableB是进程专属，但大插入可能导致临时表空间频繁扩展，这个过程会触发全局级别的锁，进而阻塞其他会话的写操作。

验证方法 #

• 执行show processlist，查看进程B的State字段是否为Waiting for table metadata lock或Waiting for redo log
• 查询performance_schema.metadata_locks表，确认是否有全局MDL锁被长时间持有
• 查看show engine innodb status的LOG段，检查Redo Log刷盘是否存在延迟

内容的提问来源于stack exchange，提问作者Vilx-