mysql 会自动加表锁的场景包括：元数据锁（mdl）读/写锁互斥、myisam引擎所有dml操作、innodb全表扫描时行锁升级、flush tables with read lock等；主动用lock tables适用于批量重写大表和规避多表死锁。
什么时候 MySQL 会自动加表锁？
MySQL 不会“凭空”加表锁，但某些操作会触发隐式或显式的表级锁定。最常见的是：访问表时自动加的元数据锁（MDL）——它本质是表级锁，且不可绕过。比如你执行 SELECT * FROM users，MySQL 就会为 users 表加一个 MDL 读锁；而此时若另一个连接正执行 ALTER TABLE users ADD COLUMN phone VARCHAR(20)，就会被阻塞，因为 DDL 需要 MDL 写锁，与读锁互斥。
其他自动触发表锁的场景包括：
- 非 InnoDB 引擎（如 MyISAM）的所有 DML 操作都会直接加表锁，
INSERT/UPDATE/DELETE全程锁整张表 - InnoDB 在 查询未命中任何索引 时（例如
WHERE name LIKE '%abc'且name无索引），优化器退化为全表扫描，行锁失效，InnoDB 会升级为锁所有聚集索引记录 → 实质等效于锁表 - 执行
FLUSH TABLES WITH READ LOCK（全局只读锁）或mysqldump --single-transaction失败回退时，也可能落到表锁路径
哪些业务场景下该主动用 LOCK TABLES？
手动加表锁不是常规操作，但在两类真实场景中仍有价值：
-
批量重写大表（>千万行）且不依赖事务一致性：比如凌晨跑 ETL 清洗日志表，逐行
UPDATE可能锁住热点行数小时，而用LOCK TABLES logs WRITE+TRUNCATE+INSERT ... SELECT能秒级完成，避免长事务拖垮并发 -
规避复杂死锁链：当多表关联更新逻辑固定、且涉及 5+ 张表时（如订单+库存+优惠券+物流+积分），按不同顺序加行锁极易死锁；统一用
LOCK TABLES t1 WRITE, t2 WRITE, t3 WRITE强制串行化，反而更稳
⚠️ 注意：LOCK TABLES 会断开当前连接的自动提交模式，且只对当前会话生效；一旦连接断开，锁自动释放 —— 所以别指望它做分布式协调。
为什么加了表锁还查不到锁冲突？
因为表锁争用不一定体现在慢查询里，而藏在状态变量中。真正反映表锁压力的是两个全局计数器：
-
table_locks_immediate：请求立即获得表锁的次数（健康值） -
table_locks_waited：请求表锁但必须等待的次数（危险信号）
运行 SHOW STATUS LIKE 'table_locks%';，如果 table_locks_waited 持续增长（比如每分钟 >10），说明存在严重表锁争用。这时要排查是否误用了 MyISAM 表、是否有缺失索引导致隐式锁表、或是否有人长期持有 WRITE 锁未释放（SHOW OPEN TABLES WHERE In_use > 0; 可查）。
InnoDB 下想避免表锁，关键就一条
确保所有带 FOR UPDATE 或 FOR SHARE 的查询都走索引，哪怕只是给 WHERE 条件字段加个单列索引。验证方法很简单：
- 先用
EXPLAIN看执行计划，确认type是const/ref/range，而非ALL - 再在事务里执行
SELECT ... FOR UPDATE后，查INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCKS（8.0+ 用performance_schema.data_locks），确认锁类型是RECORD而非TABLE
索引失效比想象中更常见：隐式类型转换（id = '123' 但 id 是 INT）、函数包裹（WHERE UPPER(name) = 'ABC'）、或联合索引没用最左前缀——这些都会让 InnoDB 放弃行锁，悄悄给你锁整张表。
