为什么MySQL普通SELECT查询也会被锁住

MySQL 中普通 SELECT 之所以会被阻塞，根源通常集中在几类锁冲突上：要么是在等待行锁释放，要么是遇到了 MDL 元数据锁冲突，再或者是被全局读锁拦住。比如在 REPEATABLE READ 隔离级别下，事务里的 SELECT 可能因为写事务长时间持有锁而进入等待；如果此时再碰到 DDL 操作，MDL 冲突发生后，就会卡在 Waiting for table metadata lock；而一旦执行了 FLUSH TABLES WITH READ LOCK，后续所有新发起的 SELECT 都可能被挂起，状态显示为 Waiting for global read lock。

普通 SELECT 本身通常不会主动加行锁，但它依然可能被锁住——本质原因不是它锁住了别人，而是它正在等待其他事务释放锁，或者被元数据锁、全局读锁直接阻塞。

为什么 SELECT 等待行锁？

关键前提是：这条 SELECT 在事务中执行，并且当前隔离级别为 REPEATABLE READ（MySQL 默认隔离级别）。

• 如果它要读取的行，正被另一个尚未提交的事务通过 UPDATE 或 DELETE 持有锁，当前 SELECT 就可能进入等待队列
• 尤其当写操作没有使用索引、导致扫描大量数据行时，锁定范围会进一步扩大，从而连带阻塞更多相关 SELECT
• EXPLAIN 通常看不出这类问题——它只能告诉你“SQL 如何执行”，却不能反映“当前是否能顺利执行”

为什么 SELECT 卡在 Waiting for table metadata lock？

这属于元数据锁（MDL）冲突，和行锁没有直接关系，但往往更隐蔽，影响范围也更大。

• 常见触发场景包括：ALTER TABLE、DROP INDEX、TRUNCATE TABLE 等 DDL 操作正在执行，并且耗时较长
• 哪怕只是一个简单的 SELECT * FROM t WHERE id = 1，只要表 t 正在被 DDL 修改，这条查询也可能被卡住
• 验证方法：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 't' AND LOCK_STATUS = 'PENDING'
• 需要注意的是：mysqldump --single-transaction 在遇到大表 ALTER 时，dump 进程本身也可能被反向阻塞

为什么 SELECT 卡在 Waiting for global read lock？

这通常不是普通并发竞争导致的，而是人为加上的全局锁引发了“整个数据库冻结”的现象。

• 根本原因往往是执行了命令：FLUSH TABLES WITH READ LOCK，执行后所有新进入的 SELECT 都可能被挂起
• 典型误用场景包括：运维备份脚本没有设置超时、旧版本迁移工具自动加锁、DBA 执行后忘记及时 UNLOCK TABLES
• 判断依据是：在 SHOW PROCESSLIST 中可以看到状态为 Waiting for global read lock 的线程，并且 Info 字段包含 FLUSH 或者为空
• 从库的 IO 线程也可能一并卡住，因为该命令会被写入 binlog 并同步到复制链路中

真正容易被忽视的是：当 SELECT 被锁住时，很多情况下既不是 SQL 语句写得差，也不是索引设计有问题，而是你没有意识到它正排队等待 MDL 锁或全局读锁释放——而这两类锁，单靠 EXPLAIN 和慢查询日志通常都无法直接发现。