MySQL 5.7 InnoDB索引更新执行机制及迁移死锁问题咨询

一、索引更新的执行方式 #

在MySQL 5.7（InnoDB引擎）中，索引更新的执行逻辑分两类场景：

• 数据变更触发的索引更新：当执行INSERT/UPDATE/DELETE这类SQL时，如果操作涉及索引列的数值变更，InnoDB会在事务内部同步完成索引维护：先修改聚簇索引（主键索引）的记录，再更新对应二级索引条目，整个过程属于SQL执行流程的核心部分，遵循事务的ACID特性，要么全部成功，要么全部回滚。
• DDL触发的索引结构更新：如果执行ALTER TABLE类语句修改索引（比如新增/删除索引、修改索引列类型），这类操作也会作为DDL语句的一部分执行。MySQL 5.7中InnoDB支持部分在线DDL，但部分操作（比如涉及索引列的重大类型变更）仍会触发表重建，过程中会维护索引结构的一致性。

针对你这次的场景：修改的updatedAt/createdAt是非索引列，理论上不会触发索引内容的更新，但该字段类型从DATETIME改为DATETIME(3)属于存储格式变更，InnoDB会重建整个表（包括分区），这个过程中会产生锁资源竞争，是后续测试出现死锁的诱因。

二、索引更新与应用代码的同步逻辑 #

是的，索引更新一定会作为对应SQL语句的执行环节完成后，应用的同步代码才会执行后续逻辑。
MySQL的SQL执行是同步阻塞模式：应用程序发送SQL请求后，会等待数据库返回执行成功的结果（或异常），只有当数据库完成所有关联操作（包括索引更新、事务提交等）后，应用代码才会推进到下一步逻辑。

内容的提问来源于stack exchange，提问作者zmii