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 写法，而是执行计划是否走了索引，以及隔离级别如何要求一致性保障。