表锁锁整张表导致所有操作阻塞，行锁仅锁匹配行但依赖索引；无索引、函数、隐式转换会使行锁退化为表锁；行锁引发死锁而表锁不会；通过Table_locks_waited和EXPLAIN可诊断锁问题。

表锁和行锁的根本区别在“锁谁”和“谁被卡住”

表锁是“一把锁关整扇门”，行锁是“给门上某把锁只锁住一个抽屉”。这不是粒度粗细的修辞，而是直接影响你线上事务是否排队、接口是否超时的真实机制。

• LOCK TABLES t1 WRITE 一执行，所有其他会话对 t1 的 SELECT、INSERT、UPDATE 全部阻塞——哪怕它们操作的是完全不同的 id
• SELECT * FROM t1 WHERE id = 100 FOR UPDATE 只锁住索引中 id=100 对应的那条记录（或索引间隙），id=101、id=200 照常被其他事务修改
• MyISAM 引擎只有表锁；InnoDB 默认用行锁，但**没走索引时会自动升级为表锁**——这是最常被忽略的坑

什么时候 MySQL 会悄悄把行锁变成表锁？

不是你写了 FOR UPDATE 就一定拿到行锁。InnoDB 行锁依赖索引，没索引=全表扫描=退化为表级锁定。

• 查询条件字段无索引：SELECT * FROM users WHERE phone = '138...' FOR UPDATE → 若 phone 未建索引，InnoDB 可能锁全表
• 使用了函数或表达式：WHERE YEAR(create_time) = 2025 → 索引失效，大概率触发表锁
• 隐式类型转换：WHERE user_id = '123'（user_id 是 INT）→ 索引可能不走，锁范围扩大
• 验证方式：执行 EXPLAIN 看 key 和 rows 字段；再查 INFORMATION_SCHEMA.INNODB_TRX 确认实际锁住的行数

行锁的代价不只是“慢”，还有死锁风险

表锁不会死锁（只有一把锁，不存在循环等待），但行锁一旦多个事务以不同顺序加锁，MySQL 就必须介入检测并回滚其中一个——你的业务代码得能处理 Deadlock found when trying to get lock 错误。

• 典型死锁场景：
  事务 A：SELECT * FROM orders WHERE id = 100 FOR UPDATE → 再 SELECT * FROM orders WHERE id = 200 FOR UPDATE
  事务 B：SELECT * FROM orders WHERE id = 200 FOR UPDATE → 再 SELECT * FROM orders WHERE id = 100 FOR UPDATE
• innodb_lock_wait_timeout 默认 50 秒，但线上建议设为 5–10 秒，避免长等待拖垮连接池
• 排他锁（FOR UPDATE）和共享锁（LOCK IN SHARE MODE）不能共存；两个共享锁可以并存，但只要来一个排他锁，全部阻塞

怎么快速判断当前系统是不是被表锁拖慢了？

别猜，直接看 MySQL 自带的状态变量，它们比慢日志更早暴露瓶颈。

SHOW STATUS LIKE 'Table_locks%';

• Table_locks_immediate：能立刻加锁的次数（越高越好）
• Table_locks_waited：需要等待表锁的次数（非零就危险，>0 表示已有争用，持续增长说明表锁成瓶颈）
• 搭配查 SHOW PROCESSLIST，看是否有大量 Waiting for table level lock 状态的线程
• 如果是 MyISAM 表，这类问题几乎无法规避；换成 InnoDB + 合理索引，才是根治方案

行锁不是银弹，它让并发变高，也把锁管理、死锁重试、索引设计这些事甩给了开发者。真正难的从来不是“怎么加锁”，而是“为什么这行没被锁住”或者“为什么整张表突然卡住了”——答案往往不在 SQL 里，而在执行计划和索引结构中。