索引失效会导致事务锁全表而非几行，因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 ('a@b.com')，而 email 是 UNIQUE 索引，MySQL 必须在索引层面做唯一性校验——这需要先查索引树确认是否已存在，再决定插入。高并发下，这个“查+插”过程极易形成循环等待。
- 现象：报错
ERROR 1213 (40001): Deadlock found when trying to get lock或ERROR 1062 (23000): Duplicate entry 'a@b.com' for key 'email' - 缓解方式：应用层加分布式锁（如 Redis），或改用
INSERT IGNORE/ON DUPLICATE KEY UPDATE避免事务级冲突 - 不推荐方案：把唯一约束挪到应用层校验——网络延迟+并发窗口会导致漏判，数据一致性无法保障
长事务让索引统计失真，优化器选错执行计划
一个运行 5 分钟的事务，期间有大量 DELETE 和 INSERT，但 information_schema.STATISTICS 里的 CARDINALITY 值不会实时更新。优化器仍按旧统计估算成本，可能放弃本该走的索引，转而选全表扫描——同一句 SQL，在事务内第一次快，第二次就变慢。
- 监控线索：查
information_schema.INNODB_TRX表，关注TRX_STARTED时间戳是否异常久 - 临时应对：手动执行
ANALYZE TABLE t，但会加MDL锁，生产环境慎用 - 根本解法：拆大事务为小批次，比如
UPDATE ... LIMIT 1000+COMMIT循环，既控锁范围，也保统计新鲜
WHERE 条件上。 
