索引是事务高效执行的前提，缺失或错误索引会导致全表扫描、大量行锁、死锁及mvcc遍历开销剧增；需为where条件建合适联合索引、避免函数操作、精简冗余索引、优先走唯一索引以缩小锁范围。
索引没建对，事务照样卡死
事务本身不解决性能问题，它只保证一致性；如果事务里执行的 UPDATE 或 SELECT ... FOR UPDATE 扫描了全表，锁住成千上万行，那阻塞、超时、死锁就都来了。索引是事务高效执行的前提，不是可选项。
常见错误：在 WHERE 条件字段上没建索引，却指望事务“自动变快”。比如：
START TRANSACTION; UPDATE orders SET status = 'shipped' WHERE user_id = 123 AND created_at > '2024-01-01'; COMMIT;
如果 user_id 和 created_at 没联合索引，MySQL 可能走 user_id 单列索引后回表过滤时间，也可能直接全表扫描——后者会让事务持有大量行锁甚至升级为表锁。
- 写事务前先
EXPLAIN对应的SELECT或UPDATE，确认是否走了索引、是否用了type=range或更好 - 复合条件优先建联合索引，顺序按「等值查询字段在前、范围查询字段在后」，例如
(user_id, created_at)而非(created_at, user_id) - 避免在索引字段上用函数或隐式类型转换，比如
WHERE DATE(created_at) = '2024-01-01'会跳过索引
事务中修改数据时，索引维护开销不能忽略
每次 INSERT/UPDATE/DELETE 都要同步更新所有相关索引，索引越多、越宽（字段多、字符长），事务的写入延迟和锁持有时间就越长。这不是理论，是 InnoDB 的实际行为。
典型场景：一张日志表有 8 个二级索引，但业务只按 trace_id 查询；结果每次写入都要维护 8 棵 B+ 树，事务平均耗时翻倍，还容易因锁等待触发 Lock wait timeout exceeded。
- 删掉长期不用的二级索引，用
information_schema.STATISTICS或sys.schema_unused_indexes（MySQL 8.0+）辅助识别 - 字符串索引慎用
FULLTEXT或长前缀（如content(255)），改用生成列 + 索引更可控 - 高频更新的字段尽量别建索引，比如
updated_at单独建索引，除非你真要用它查“最近更新的记录”
长事务 + 非唯一索引 = 隐形死锁高发区
InnoDB 在非唯一索引上加锁时，会锁定查找路径上的“间隙（gap）”，而不仅是匹配到的记录。如果两个事务先后执行相似的 SELECT ... FOR UPDATE 且没走唯一索引，很容易互相等待对方释放 gap 锁，形成死锁。
