表锁锁整张表导致所有操作阻塞，行锁仅锁匹配行但依赖索引；无索引、函数、隐式转换会使行锁退化为表锁；行锁引发死锁而表锁不会；通过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 里，而在执行计划和索引结构中。
