索引失效会导致事务锁全表而非几行，因InnoDB无法精确定位而触发全表扫描与Next-Key Lock；复合索引设计不当会扩大锁范围；唯一索引冲突易引发死锁；长事务使统计失真致执行计划变差。
索引失效时，事务会锁全表而不是几行
事务中一条 UPDATE 或 SELECT ... FOR UPDATE 如果没走索引，InnoDB 就没法精确定位数据，只能扫全表——每扫一页就加一个意向排他锁（IX），再对实际匹配的行加行锁。但更糟的是：在 REPEATABLE READ 隔离级别下，全表扫描会触发大量 Next-Key Lock，把整个聚簇索引都锁住，其他事务一碰这张表就卡死。
- 常见诱因：
WHERE name LIKE '%abc'、WHERE status + 0 = 1（隐式转换）、WHERE id = '123'（id 是 int 但传了字符串） - 验证方法：执行
EXPLAIN FORMAT=TRADITIONAL SELECT ... FOR UPDATE，看type是不是ALL或index，key列是不是NULL - 修复动作：加索引只是第一步；必须确保查询条件能命中它，比如改
status + 0 = 1为status = 1，或给name加前缀索引后改写成WHERE name LIKE 'abc%'
复合索引设计错，事务锁得更多、更久
事务里执行 UPDATE orders SET paid_at = NOW() WHERE user_id = ? AND status = 'unpaid'，如果只在 user_id 上建单列索引，InnoDB 得先通过索引找到所有该用户的订单，再逐行回表读 status 值过滤——这意味着所有 user_id 匹配的行都会被加锁，哪怕其中 95% 的 status 是 'paid'。
- 正确做法：建
(user_id, status)复合索引，让过滤在二级索引页内完成，锁只落在真正匹配的几行上 - 注意最左前缀：
WHERE status = 'unpaid'单独用这个索引是无效的；但如果加了ORDER BY user_id，它就能用上 - 高频更新列慎放左边：比如
(status, user_id)，每次改status都要删旧索引项+插新项，B+ 树分裂频繁，事务延迟上升
唯一索引冲突直接引发死锁或回滚
两个并发事务同时执行 INSERT INTO users (email) VALUES ('[email protected]')，而 email 是 UNIQUE 索引，MySQL 必须在索引层面做唯一性校验——这需要先查索引树确认是否已存在，再决定插入。高并发下，这个“查+插”过程极易形成循环等待。
