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) = '2024-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冲突规则不同，这点常被忽略。
