显式锁（如lock tables）反而更慢，因其绕过innodb行级锁强制升级为表级锁，导致整表阻塞；常见误用包括未配unlock、混用事务语句、滥用read锁及for update无索引等。
隐式锁升级为显式锁后，为什么反而更慢了
不是“加了锁就一定更稳”，而是显式锁（比如 LOCK TABLES）直接绕过 InnoDB 的行级锁机制，强制升为表级锁。哪怕你只改一行数据，LOCK TABLES products WRITE 也会让整张表对其他读写请求阻塞——这和业务预期的“精准控制”完全相反，高并发下 QPS 断崖下跌是常态。
哪些场景会误用显式锁并拖垮性能
常见于老代码迁移、MyISAM 风格习惯残留，或对事务边界理解模糊。以下操作极易踩坑：
-
LOCK TABLES后没配UNLOCK TABLES，锁长期持有，后续所有语句排队等待 - 在事务中混用
LOCK TABLES和BEGIN/COMMIT，InnoDB 不兼容这种组合，可能触发隐式提交+锁释放失控 - 用
LOCK TABLES ... READ做“只读保护”，但前端接口高频调用，大量只读连接争抢同一把读锁，形成串行瓶颈 - 以为
SELECT ... FOR UPDATE是“显式锁替代方案”，结果 WHERE 条件没走索引，直接升级为全表扫描 + 表级 X 锁
真正该用什么替代 LOCK TABLES
绝大多数需要“显式控制”的业务场景，根本不需要表锁。正确路径是回归 InnoDB 原生机制：
- 需要确保更新前数据未被修改 → 用
SELECT ... FOR UPDATE，但必须保证WHERE字段有索引，且事务尽量短 - 要避免幻读又不想锁太死 → 改用
SELECT ... LOCK IN SHARE MODE+ 合理隔离级别（RR 下配合间隙锁已足够） - 批量更新/插入需防并发冲突 → 用唯一键约束 +
INSERT ... ON DUPLICATE KEY UPDATE，靠索引冲突兜底，不依赖锁 - 跨多行强一致性操作 → 拆成小事务 + 应用层重试，比锁整张表更可控
检查是否已被显式锁拖累
别只看慢查询日志，重点查锁状态：
- 执行
SHOW OPEN TABLES WHERE In_use > 0，看是否有表长期显示In_use = 1 - 运行
SHOW PROCESSLIST，找大量Waiting for table level lock状态的线程 - 查状态变量：
SHOW STATUS LIKE 'Table_locks_waited'，若该值持续增长，说明表锁争用严重 - 确认有没有应用代码里藏着
LOCK TABLES—— 尤其是 DAO 层封装、历史遗留存储过程、定时任务脚本
最隐蔽的性能断点往往不在 SQL 写法本身，而在锁粒度与业务意图错配：你想要的是“某订单的优惠券核销锁定”，结果代码却锁了整张 coupon_usage 表。这种偏差不会报错，只会让数据库在高并发下越来越沉默。
