行锁只在索引字段上生效，非索引字段会退化为表锁
MySQL 的行级锁（如
SELECT ... FOR UPDATE）实际加锁对象不是“行”，而是“索引记录”。如果
WHERE条件中使用的字段没有索引，InnoDB 无法精确定位记录，就会对所有扫描过的聚簇索引页加锁——这等价于锁住整张表的大部分甚至全部数据行，造成事实上的表级阻塞。
常见错误现象：
UPDATE users SET status = 1 WHERE phone = '138...'执行缓慢且阻塞其他事务，而
EXPLAIN显示
type: ALL（全表扫描）。 确认加锁字段是否已建索引：
SHOW INDEX FROM users WHERE Key_name != 'PRIMARY';联合索引要注意最左匹配：用
WHERE name = ? AND city = ?时，
(city, name)索引无效，需建
(name, city)
LIKE查询以通配符开头（如
LIKE '%abc'）无法使用索引，同样触发全扫描加锁
间隙锁（Gap Lock）和临键锁（Next-Key Lock）才是防止幻读的关键
很多人以为
SELECT ... FOR UPDATE只锁已有行，其实 InnoDB 在可重复读（RR）隔离级别下默认使用
Next-Key Lock—— 即“行锁 + 间隙锁”的组合。它不仅锁住匹配的索引记录，还锁住该记录前后的索引间隙，阻止新记录插入到这些间隙中。
典型场景：事务 A 执行
SELECT * FROM orders WHERE order_no > 100 FOR UPDATE，事务 B 尝试插入
order_no = 105会被阻塞，即使该值当前不存在。 间隙锁只在 RR 隔离级别下启用；读已提交（RC）下仅用行锁，不加间隙锁 主键或唯一索引的等值查询（如
WHERE id = 10）只锁具体记录，不锁间隙 普通索引的等值查询仍会加 Next-Key Lock，比如
WHERE idx_col = 5会锁住 (3,5] 和 (5,8] 这类区间
显式加锁语句必须在事务内执行，否则立即释放
SELECT ... FOR UPDATE或
SELECT ... LOCK IN SHARE MODE不是“持久锁”，它们的生命周期完全绑定于当前事务。一旦执行
COMMIT或
ROLLBACK，锁立刻释放；若不在事务中执行，语句执行完即释放，起不到并发控制作用。
容易踩的坑：
autocommit = 1下直接写
SELECT ... FOR UPDATE，看似加了锁，实则锁在语句结束瞬间就没了，其他事务能立刻修改同一行。 务必先执行
START TRANSACTION或设置
SET autocommit = 0避免在长事务中持有锁太久，尤其是高并发写场景，容易引发锁等待超时（
Lock wait timeout exceeded） 不要依赖锁来实现业务逻辑中的“抢购”“库存扣减”等关键操作，应配合应用层重试 + 数据库原子更新（如
UPDATE stock SET count = count - 1 WHERE id = 1 AND count >= 1）
死锁检测开销不可忽视，高频小事务反而更容易触发
InnoDB 死锁检测是主动遍历等待图（wait-for graph），每发生一次锁等待就会触发一次检测。当事务非常短、并发极高时（例如秒杀场景下的单条
UPDATE），大量事务几乎同时请求不同顺序的资源，死锁概率不降反升。
错误认知：“锁粒度越小越安全”——但行锁数量多、加锁顺序稍有不一致，就比粗粒度表锁更易形成环形等待。
查看最近死锁日志：SHOW ENGINE INNODB STATUS\G，重点关注
LATEST DETECTED DEADLOCK段 统一加锁顺序：比如所有业务都按
user_id升序处理多行更新，避免 A 锁 1 再锁 2、B 锁 2 再锁 1 允许应用捕获
Deadlock found when trying to get lock错误并自动重试，而不是调大
innodb_lock_wait_timeout
实际生产中，锁行为高度依赖索引结构、查询条件、隔离级别与事务边界。没有“通用最优锁策略”，只有针对具体 SQL 和业务语义做精准分析。别只看执行计划，一定要结合
INFORMATION_SCHEMA.INNODB_TRX和
INNODB_LOCKS（MySQL 5.7）或
performance_schema.data_locks（8.0+）实时观察锁状态。
