表锁和行锁的根本区别在“锁谁”和“谁被卡住”
表锁是“一把锁关整扇门”，行锁是“给门上某把锁只锁住一个抽屉”。这不是粒度粗细的修辞，而是直接影响你线上事务是否排队、接口是否超时的真实机制。
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 里，而在执行计划和索引结构中。
