行锁实际作用于索引记录，非索引字段导致全表扫描并退化为表级阻塞；RR级别下默认使用Next-Key Lock（行锁+间隙锁）防幻读；显式加锁需在事务内执行，否则立即释放；死锁高发于高频小事务，需统一加锁顺序并配合应用重试。
行锁只在索引字段上生效，非索引字段会退化为表锁
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，锁立刻释放；若不在事务中执行，语句执行完即释放，起不到并发控制作用。
citySHOP是一款集CMS、网店、商品、分类信息、论坛等为一体的城市多用户商城系统，已完美整合目前流行的Discuz! 6.0论坛，采用最新的5.0版PHP+MYSQL技术。面向对象的数据库连接机制，缓存及80%静态化处理，使它能最大程度减轻服务器负担，为您节约建设成本。多级店铺区分及联盟商户地图标注，实体店与虚拟完美结合。个性化的店铺系统，会员后台一体化管理。后台登陆初始网站密匙：LOVES
容易踩的坑：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+）实时观察锁状态。
