MySQL中事务与索引无直接依赖但相互影响：事务写操作需同步维护索引，索引影响锁粒度、并发性及性能，索引变更随事务原子性保证一致，且仅在COMMIT后持久化。
MySQL 中事务和索引没有直接的依赖关系，但它们在实际运行中会相互影响——事务操作（尤其是写操作）需要维护索引，而索引的存在又会影响事务的执行效率和并发行为。
事务执行时会触发索引维护
当事务中包含 INSERT、UPDATE、DELETE 操作时，只要涉及的列上有索引，MySQL 就必须同步更新这些索引结构：
- 插入新行：除了写入数据页，还要在对应索引树（如 B+Tree）中插入键值和指针；
- 修改主键或索引列：相当于先删后插，可能引发索引分裂或页合并；
- 删除记录：需从数据页和所有相关索引中移除对应条目；
- 回滚（ROLLBACK）时：已做的索引变更也要一并撤销，这部分开销常被忽略但真实存在。
索引会影响事务的锁行为和隔离性
索引不仅加速查询，还决定 MySQL 加锁的粒度和范围，进而影响事务并发能力：
- 有索引的 WHERE 条件（如 WHERE id = 100）通常只锁匹配的单行（行级锁）；
- 没索引或索引失效时（如 WHERE name LIKE '%abc'），可能升级为全表扫描+表级锁或间隙锁膨胀；
- 在可重复读（RR）隔离级别下，范围查询（如 WHERE age BETWEEN 20 AND 30）若 age 列有索引，会加间隙锁（Gap Lock）防止幻读；没索引则可能锁住整个聚簇索引，大幅降低并发。
索引设计不当会拖慢事务性能
高频写入的表如果索引过多或不合理，会让事务变慢甚至成为瓶颈：
- 每多一个索引，INSERT/UPDATE/DELETE 就要多维护一份 B+Tree，写放大明显；
- 复合索引未遵循最左前缀原则，导致部分 UPDATE 无法利用索引快速定位，被迫全表扫描；
- 对频繁更新的列建索引（如状态字段 status），每次修改都触发索引结构调整，增加事务延迟和死锁概率。
事务不保证索引一致性，但索引依赖事务持久性
索引本身不是事务对象，它不参与原子性控制——比如一个事务里删了 10 行，其中 3 行索引更新失败，整个事务会回滚，不会留下“半更新”的索引状态。但反过来说：
- 只有事务成功 COMMIT 后，对应的索引变更才真正落盘并对外可见；
- 崩溃恢复时，MySQL 依靠 redo log 重放已提交事务的操作，包括索引页的修改，确保索引与数据最终一致。
