行锁必须落在索引上，因InnoDB是索引组织表，数据行物理存储于聚簇索引叶子节点，无脱离索引的独立数据行；锁绑定索引项才能借助B+树实现O(log n)锁查找与冲突检测。
行锁为什么必须落在索引上，而不是数据行本身
因为InnoDB是索引组织表（IOT），数据行物理上就存放在聚簇索引的B+树叶子节点里——没有脱离索引的“纯数据行”。锁若直接打在数据页的某几字节上，事务并发时无法快速判断“谁在改哪条记录”，每次定位都要全表扫描，性能归零。所以InnoDB把锁信息绑定到索引项（index record）上，靠B+树的有序结构实现O(log n)级别的锁查找和冲突检测。
这就像快递柜：柜子编号（索引键）是唯一寻址依据，你不能说“锁住第3层左数第2格的塑料托盘”（物理位置），而必须说“锁住柜号207A”（逻辑标识）。否则换一次货柜布局，所有锁都失效。
没索引时行锁就退化成表锁
当WHERE条件无法命中任何索引（比如对无索引列查询、隐式类型转换、函数包裹字段），InnoDB只能走聚簇索引全表扫描。它会为扫描路径上的每个索引项（包括所有记录和间隙）逐一加锁——效果等同于锁整张表，只是底层实现仍叫“行锁”，实际已失去行级并发意义。
常见错误现象：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
UPDATE t SET status=1 WHERE phone='138xxxx' AND deleted=0;，但phone和deleted都没索引 → 锁全部主键记录 -
SELECT * FROM user WHERE id+1=100;，id虽为主键，但加了函数 → 索引失效，全表扫描加锁 - 字符串字段用数字比较：
WHERE mobile = 13800138000，mobile是VARCHAR→ 隐式转换导致索引失效
不同索引类型，锁的位置和范围不一样
锁加在哪、加多大范围，取决于你查的是哪个索引、以及隔离级别：
- 用主键查：
SELECT ... FOR UPDATE WHERE id=100→ 只锁聚簇索引中id=100那条index record - 用唯一二级索引查：
SELECT ... FOR UPDATE WHERE username='alice'→ 先锁username索引项，再通过回表拿到主键值，再锁对应聚簇索引记录 - 用非唯一二级索引查：
SELECT ... FOR UPDATE WHERE status=1→ 锁所有匹配的二级索引项，且每条都触发回表并锁对应聚簇索引记录；RR级别下还会锁这些记录之间的gap - 范围查询：
WHERE age BETWEEN 25 AND 30→ RR下锁的是Next-Key Lock，即每个匹配记录 + 它前面的间隙，可能覆盖20→25、25→30、30→35多个gap
RC和RR隔离级别下，锁行为差异极大
很多人以为“加了FOR UPDATE就一定锁行”，其实RC和RR对锁的持有逻辑完全不同：
- RC级别：
UPDATE只加Record Lock，语句执行完立刻释放不匹配的行锁；不使用Gap Lock，所以不会阻塞其他事务往间隙插数据，幻读可能发生，但死锁概率低 - RR级别：
UPDATE默认用Next-Key Lock（Record Lock + Gap Lock），锁持续到事务提交；范围查询会锁住整个扫描区间，防幻读但也容易引发间隙冲突 - 关键影响：
SELECT ... FOR UPDATE WHERE id > 100 LIMIT 1在RR下可能锁住101之后所有间隙，而RC下只锁实际命中的那一行
真正容易被忽略的点是：锁的粒度和生命周期，不是由SQL写法单独决定的，而是索引选择 × 隔离级别 × 查询条件是否范围 三者共同作用的结果。看执行计划（EXPLAIN）只能告诉你走了哪个索引，没法直接看出锁了哪些记录和间隙——得结合INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCKS（MySQL 8.0后为performance_schema.data_locks）实时抓取才看得见。
