索引失效时，事务会锁全表而不是几行
事务中一条
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')，而 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条件上。
