lock tables table_name write 会阻塞所有其他会话的读写操作，包括 select，直至执行 unlock tables 或会话断开；当前会话获得独占访问权，且未锁表不可访问，事务中执行会隐式提交。
LOCK TABLES WRITE 会阻塞所有其他会话的读写
执行 LOCK TABLES table_name WRITE 后，当前会话获得该表的独占访问权，其他任何会话（包括只读 SELECT）都会被挂起，直到你执行 UNLOCK TABLES 或会话断开。这不是“建议性锁”，而是硬性阻塞——哪怕另一个会话只想 SELECT COUNT(*)，也会卡住。
常见错误现象：
- 其他会话在执行 SELECT 时长时间无响应，SHOW PROCESSLIST 显示状态为 Waiting for table level lock
- 应用层超时、连接池耗尽、监控报警突增
- 必须确保当前会话已具备
LOCK TABLES和SELECT权限，否则直接报错ERROR 1045 (28000): Access denied - 不能在事务中混用：如果已开启
BEGIN或START TRANSACTION，执行LOCK TABLES会隐式提交并释放事务，导致意外的数据提交 - 锁定后，只能操作被显式锁定的表；访问未锁表会报错
Table 'xxx' was not locked with LOCK TABLES
READ 锁不是“只读事务”，它允许并发读但禁止写
LOCK TABLES table_name READ 常被误认为是“安全只读模式”，但它不阻止其他会话同时加 READ 锁，也不提供一致性快照——多个会话可能读到不同时间点的数据，且任何 INSERT/UPDATE/DELETE 都会被阻塞。
典型使用场景：
- MyISAM 表做批量校验（如 checksum 对比）
- 短时导出前冻结写入，但允许监控或报表查询继续读
-
READ锁下，当前会话仍不能写，哪怕只是INSERT一行也会报错 - 如果表有外键关联，MySQL 会自动对相关表加
READ锁（即使你没显式声明），可能意外扩大锁范围 - MyISAM 引擎下，
READ锁可与CONCURRENT INSERT共存（仅限表尾追加），但 InnoDB 不支持该特性
UNLOCK TABLES 不只是释放锁，还会隐式提交
执行 UNLOCK TABLES 时，如果当前会话处于 autocommit = 0 状态，MySQL 会**自动提交当前事务**——这是极易被忽略的副作用。你以为还在事务里，其实已经提交了。
更隐蔽的问题：
- 如果之前执行过 LOCK TABLES，再执行 START TRANSACTION，会先释放所有表锁，然后才开启新事务
- 同一会话重复执行 LOCK TABLES（如先锁 A，再锁 B），旧锁会被自动释放，不会叠加
- 高风险组合：
BEGIN; LOCK TABLES t1 WRITE; UPDATE t1 ...; UNLOCK TABLES;→UPDATE已提交，无法回滚 - 想保持事务控制，必须设
SET autocommit = 1，让每个语句独立提交，再用LOCK TABLES控制表级互斥 - 会话异常断开（如网络中断）时，MySQL 会自动清理该会话持有的所有表锁，无需人工干预
InnoDB 下优先用行锁，表锁是退路不是首选
InnoDB 默认通过 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 实现行级并发控制。LOCK TABLES 在 InnoDB 中属于“绕过引擎原生机制”的粗粒度手段，仅应在以下情况考虑：
- 全表扫描类 DML（如
UPDATE t SET x=1 WHERE y IS NULL且y无索引），InnoDB 可能升级为表锁，此时显式加锁反而更可控 - 跨多张表的原子性维护（如更新用户余额 + 记录流水），且无法用单事务包裹（例如涉及外部系统调用）
- 维护任务：OPTIMIZE TABLE、ANALYZE TABLE 或修复 MyISAM 表
容易踩的坑：
- 在 InnoDB 表上用 WRITE 锁，却忘了它会阻塞 SELECT（哪怕只是 SELECT 1），而行锁不会
- 依赖 LOCK TABLES 实现“分布式锁”效果，但 MySQL 重启或主从切换后状态丢失，不可靠
- 混用存储引擎：同一 LOCK TABLES 语句中同时锁 MyISAM 和 InnoDB 表，行为不一致且难调试
