MySQL 事务本身不会直接改变索引的结构或内容，但在事务执行过程中，对数据的修改会间接影响索引的行为和性能。理解事务与索引之间的交互，有助于优化数据库设计和提升并发处理能力。
事务中的数据变更会触发索引更新
当事务中执行 INSERT、UPDATE 或 DELETE 操作时，MySQL 不仅要修改表中的数据行，还需要同步维护对应的索引。
例如：
插入一条记录时，所有该表上的索引（包括主键、唯一索引、普通索引等）都需要添加新的索引项。 更新被索引的列时，旧的索引项需要删除，新的索引项需要插入。 删除记录时，对应的所有索引条目也必须标记为删除（实际清除通常在事务提交后由后台线程完成）。这些操作在事务未提交前，会在 undo log 和 redo log 中记录，并通过 MVCC（多版本并发控制）机制保证其他事务看到一致的索引视图。
事务隔离级别影响索引的可见性
不同的隔离级别决定了事务能否“看到”其他事务对索引数据的更改，从而影响查询结果和加锁行为。
在 READ COMMITTED 或 REPEATABLE READ 下，InnoDB 使用间隙锁（gap lock）或临键锁（next-key lock）来防止幻读，这些锁会作用在索引上。 如果查询条件使用了索引，InnoDB 通常会对匹配的索引记录加锁；如果没有索引，则可能升级为表锁或全扫描加锁，严重影响并发。 长时间运行的事务可能导致索引上的锁持有时间变长，阻塞其他事务对相同索引范围的操作。大事务可能导致索引性能下降
长时间运行的事务或批量操作会带来以下问题：
undo 日志持续增长，影响回滚段管理，间接拖慢索引维护速度。 MVCC 快照保留更多历史版本，导致索引扫描时需要跳过已被删除但尚未 purge 的记录，增加 I/O 和 CPU 开销。 大量临时索引变更堆积在 buffer pool 中，可能引发频繁刷盘，降低整体性能。建议避免在一个事务中一次性修改大量带索引的数据，尤其是高频更新索引列的情况。
合理设计索引可减少事务冲突
良好的索引策略能显著降低事务间的锁竞争：
为 WHERE、JOIN、ORDER BY 条件创建合适的索引，使事务能快速定位并锁定最小范围的记录。 避免冗余索引，减少每次 DML 操作需要维护的索引数量。 使用覆盖索引可以避免回表，减少事务中访问主键索引的频率。比如，在高并发写入场景下，自增主键比 UUID 更利于减少页分裂和索引碎片，从而提升事务效率。
基本上就这些。事务和索引的协同工作是 MySQL 性能的关键环节，理解它们的相互影响，才能写出高效稳定的数据库应用。
