MySQL行级锁失效主因是WHERE条件未走索引，导致全表扫描并加锁；事务中非DB操作会延长锁持有时间；RR级别用next-key lock防幻读但易冲突，RC级别仅record lock并发更高；需用INNODB_TRX等视图验证实际锁类型。
MySQL 的行级锁在高并发下为什么没生效？
根本原因通常是 WHERE 条件未命中索引，导致 InnoDB 退化为表级锁或锁住过多记录。比如执行 UPDATE user SET status = 1 WHERE name = 'alice'，而 name 字段没有索引，InnoDB 只能扫描全表并给所
有扫描过的行加 record lock，甚至可能升级为 gap lock 或 next-key lock，造成大面积阻塞。
实操建议：
- 用
EXPLAIN检查所有写语句的执行计划，确保type至少是ref或更优，key显示实际使用的索引 - 对高频更新字段（如
status、version、updated_at）建立联合索引时，把WHERE条件列放在最左，更新列无需单独建索引 - 避免在
WHERE中对字段使用函数或隐式类型转换，例如WHERE DATE(create_time) = '2025-01-01'会失效索引
事务中哪些操作会意外延长锁持有时间？
锁不是在语句结束就释放，而是在事务提交（COMMIT）或回滚（ROLLBACK）后才统一释放。任何在事务内引入延迟的操作，都会把锁“拖长”——这是高并发下死锁和超时的主因。
常见陷阱：
- 在事务里调用外部 HTTP 接口、读取大文件、做复杂计算，这些不涉及数据库的操作，却让锁持续几十秒甚至分钟
- 事务内嵌套了另一个慢查询（如未优化的子查询或
JOIN），导致整个事务卡在某条语句上 - 应用层用了连接池但未正确关闭事务（比如异常未
ROLLBACK），连接被复用后旧事务状态残留
解决方向：把非数据库逻辑移出事务；用 SELECT ... FOR UPDATE 前先校验前置条件；设置 innodb_lock_wait_timeout 并捕获 Lock wait timeout exceeded 错误主动重试。
READ COMMITTED 和 REPEATABLE READ 隔离级别对锁行为的影响差异
InnoDB 默认的 REPEATABLE READ 并非完全“可重复读”，它通过 next-key lock 防止幻读，但代价是范围查询（如 WHERE id > 100）会锁住间隙，容易引发冲突。而 READ COMMITTED 下只加 record lock，不加 gap lock，锁更轻、并发更高，但需业务接受“不可重复读”。
选型参考：
- 支付类强一致性场景（如扣减余额+生成订单），必须用
REPEATABLE READ，且显式加SELECT ... FOR UPDATE确保同一行不被并发修改 - 日志类、统计类、状态轮询类业务，可用
READ COMMITTED，配合应用层幂等处理，显著降低锁冲突概率 - 切忌混用：同一业务模块若部分接口设
READ COMMITTED，部分依赖默认隔离级别，会出现难以复现的数据可见性问题
如何验证当前 SQL 实际加了什么锁？
不能只靠推测。MySQL 提供了直接观测手段，关键看 INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS（8.0 已移除）和 INNODB_LOCK_WAITS，但更实用的是 sys.innodb_lock_waits 视图（需启用 performance_schema）。
快速定位步骤：
- 查活跃事务：
SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX ORDER BY trx_started;
- 查锁等待关系：
SELECT * FROM sys.innodb_lock_waits;
输出含阻塞事务 ID、被阻塞 SQL、等待锁类型等 - 查具体锁信息（需权限）：
SELECT * FROM performance_schema.data_locks;
注意LOCK_TYPE（RECORD / TABLE）、LOCK_MODE（X / S / GAP / INSERT_INTENTION）
真正难的不是看到锁，而是理解为什么加这个锁——比如 INSERT 在唯一索引冲突时会加 insert intention lock，和普通 X lock 冲突规则不同，这点常被忽略。
