MySQL 在特定场景下自动加表锁：WHERE 条件未命中索引导致全表扫描、DDL 操作触发 MDL 锁、MyISAM 引擎默认表级锁、InnoDB 因索引失效或优化器弃用索引而退化为表锁。

什么时候 MySQL 会自动加表锁？

MySQL 不会“随意”加表锁，但会在特定场景下由系统隐式触发，尤其是当行级锁无法安全或高效工作时。InnoDB 默认用行锁，但一旦条件不满足，就会退化为表锁——这不是 bug，而是设计兜底。

• UPDATE 或 DELETE 语句的 WHERE 条件未命中索引（如字段无索引、类型不匹配、函数包裹导致索引失效），InnoDB 必须全表扫描，于是给所有聚集索引记录加锁 → 实质锁整张表
• 执行 ALTER TABLE、DROP TABLE 等 DDL 操作时，MySQL 自动加 元数据锁（MDL），这是一种表级排他锁，会阻塞后续所有 DML（哪怕只是 SELECT）
• 长事务中持有 MDL 读锁（比如一个慢查询没结束），此时 DDL 会被卡住，而后续所有试图访问该表的事务也会排队等待 MDL，形成“锁链式阻塞”
• 在 READ COMMITTED 或 REPEATABLE READ 隔离级别下，全表扫描的 SELECT（如 SELECT * FROM orders WHERE create_time ）虽不加行锁，但会持意向共享锁（IS），若此时有其他事务正尝试加表级写锁（如 LOCK TABLES ... WRITE），就会被阻塞

哪些业务场景适合主动加表锁？

手动加表锁不是日常操作，而是应对特定高风险批量任务的“手术刀式干预”。它牺牲并发换确定性，只在必要时用。

• 主从同步建库前的短暂冻结：在从库拉取主库快照前，用 FLUSH TABLES WITH READ LOCK 锁住所有表，确保一致性；注意该命令会阻塞所有写入，且不能在已有活跃事务时执行
• 超大表的全量更新/归档：比如对上亿行的 log_archive 表执行 UPDATE ... SET status=1，若走行锁，可能锁数小时并引发大量死锁；改用 LOCK TABLES log_archive WRITE + 批量更新 + UNLOCK TABLES，反而更稳
• 避免复杂多表事务中的死锁雪崩：当多个服务频繁交叉更新 3 张以上关联表（如 orders、inventory、payments），且顺序难以统一时，可临时约定按固定顺序加表锁，打破循环等待链

表锁 vs 行锁：关键参数和代价怎么算？

别只看“锁得快”，要看“等得多”。MySQL 提供两个状态变量帮你判断表锁是否已成为瓶颈：

SHOW STATUS LIKE 'table_locks%';

重点关注：

• table_locks_immediate：请求立即获得表锁的次数（越接近总请求数越好）
• table_locks_waited：因表锁冲突而被迫等待的次数（> 0 就说明已有争用；持续增长需警惕）

另外要注意：LOCK TABLES 是**会话级**的，且与事务无关——即使你没开 BEGIN，只要没执行 UNLOCK TABLES，锁就一直挂着，还可能干扰备份工具（如 mysqldump --single-transaction 在遇到显式表锁时会自动降级为 --lock-all-tables）

最容易被忽略的坑：MyISAM 和隐式锁升级

如果你还在用 MyISAM 引擎（比如老日志表），那根本不用“加”表锁——它所有 SELECT 默认加共享锁，所有 INSERT/UPDATE/DELETE 默认加排他锁，完全没法并发写。这不是配置问题，是引擎限制。

更隐蔽的是 InnoDB 的“伪行锁”陷阱：

• 一张表有 id 主键，但你写 UPDATE users SET name='x' WHERE phone='138...'，而 phone 字段没索引 → 全表扫描 → 所有主键记录都被加上 X 锁 → 效果等同于表锁
• 即使有索引，若用了 OR、NOT IN、LIKE '%abc' 等让优化器放弃索引的写法，同样触发锁表
• 使用 SELECT ... FOR UPDATE 时，若 WHERE 条件返回空结果集，InnoDB 在 RR 隔离级别下仍可能加 Gap Lock 锁住整个范围——看似没锁数据，实则锁住了插入空间

真正决定锁粒度的从来不是你的 SQL 写法，而是执行计划是否走了索引，以及隔离级别如何要求一致性保障。