什么时候 MySQL 会用表锁而不是行锁
MySQL 默认在
InnoDB引擎下走行锁，但一旦查询无法使用索引、或用了
SELECT ... FOR UPDATE/
UPDATE时走了全表扫描，InnoDB 就会升级为表锁（更准确地说：对所有扫描过的索引记录加锁，再配合间隙锁，实际效果接近锁整张表）。
常见触发场景包括：
WHERE条件字段没建索引，或索引失效（比如对索引列做函数操作：
WHERE YEAR(create_time) = 2024） 使用
LIKE '%abc'导致索引无法命中 执行
ALTER TABLE（尤其是非原子 DDL，在老版本 MySQL 中会锁表） 显式使用
LOCK TABLES ... WRITE（MyISAM 默认行为，InnoDB 不推荐）
InnoDB 行锁的三种类型怎么影响并发
InnoDB 的行锁不是“锁某一行”，而是基于索引记录的锁，分三类：
Record Lock：锁住索引中某条具体记录（如主键值为
100的行）
Gap Lock：锁住索引记录之间的“间隙”，防止幻读（例如锁定
(10, 20)这个范围，不允许插入
15）
Next-Key Lock：
Record Lock + Gap Lock的组合，是 InnoDB 默认的可重复读（
REPEATABLE READ）隔离级别下的行锁行为
关键点：
没有索引的表？InnoDB 会为隐式聚簇索引（即主键）加锁；若没定义主键，它会自建一个隐藏的row_id索引——这时锁行为难以预测，且容易锁多 唯一索引等值查询（
WHERE id = 123），只加
Record Lock；范围查询（
WHERE id > 100）则必然带
Gap Lock想禁用间隙锁？可临时设
SET SESSION transaction_isolation = 'READ-COMMITTED'，但需同步评估幻读风险
如何确认当前 SQL 到底锁了什么
不能靠猜。得用 InnoDB 的信息视图定位真实锁状态：
查正在运行的阻塞事务：SELECT * FROM information_schema.INNODB_TRX;查锁等待关系：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;查具体锁信息（记录锁在哪、锁类型、事务 ID）：
SELECT * FROM information_schema.INNODB_LOCKS;（注意：8.0+ 已移除此视图，改用
performance_schema.data_locks） 快速看谁卡住了你：
SELECT BLOCKING_TRX_ID, BLOCKED_TRX_ID FROM performance_schema.data_lock_waits;
特别提醒：
SHOW ENGINE INNODB STATUS\G输出里
TRANSACTIONS部分有最实时的锁等待堆栈，但只保留最近一次死锁信息，且输出易被截断。
表锁与行锁的优化关键其实是索引和事务粒度
真正决定锁范围的，从来不是“选表锁还是行锁”，而是“SQL 走不走得上索引”和“事务包多大”。优化方向很实在：
所有WHERE、
JOIN、
ORDER BY字段必须有合适索引；用
EXPLAIN确认
type是
ref/
range，而非
ALL或
index避免长事务：事务开启后不做任何操作却迟迟不提交，会让锁一直挂着；尤其警惕 ORM 框架里隐式开启又忘记
commit的事务 写操作尽量走主键或唯一索引更新，避免
UPDATE ... WHERE non_unique_col = ?触发范围锁扩散 高并发更新同一行？考虑用应用层重试 + 乐观锁（如
version字段）替代悲观锁，减少锁冲突
最常被忽略的一点：
autocommit=1是默认，但某些客户端或框架会关掉它；一旦关了，每个语句都成独立事务，看似没写
BEGIN，实则每条
UPDATE都在持锁直到下次
COMMIT—— 这种隐式锁行为，比表锁还难排查。
