modify column ... after 必须全表重建，因innodb行存储依赖字段顺序决定字节偏移量，调整即重写每行物理记录，强制algorithm=copy、持mdl_exclusive锁、阻塞所有dml。
不能直接用 DDL 安全、高效地修改列位置顺序——只要带 AFTER 或 FIRST，就等于触发全表重建。
为什么 MODIFY COLUMN ... AFTER 一定会锁表且慢
这不是 MySQL “没优化好”，而是 InnoDB 行存储机制决定的：字段顺序 = 每行各字段的字节偏移量。改顺序 → 偏移量全乱 → 必须逐行重写物理记录。哪怕只有 1 行，也会走 ALGORITHM=COPY，全程持 MDL_EXCLUSIVE 锁，阻塞所有 INSERT/UPDATE/DELETE。
-
SHOW PROCESSLIST里会看到状态为copy to tmp table -
performance_schema.table_io_waits_summary_by_table中原表COUNT_READ和新表COUNT_WRITE同步飙升 - 即使开了
innodb_file_per_table=ON，I/O 和锁等待仍无法规避
MySQL 8.0 的 INSTANT 算法支持改列顺序吗
仅在极有限条件下支持：MySQL 8.0.29+ 且使用 ALGORITHM=INSTANT 时，ADD COLUMN 可指定位置（如 AFTER x），但这是“新增列放中间”，不是“移动已有列”。对已存在列调用 CHANGE COLUMN ... AFTER 或 MODIFY COLUMN ... FIRST，仍强制退化为 COPY。
- 检查当前默认算法：
SELECT @@innodb_alter_table_default_algorithm;（值为instant仅影响新增列） - 显式指定无效：
ALTER TABLE t CHANGE c c INT AFTER id, ALGORITHM=INSTANT;会报错或静默降级 - 真正 INSTANT 的操作只有：加列（末尾或指定位置）、删列（标记隐藏）、改默认值、改列注释
真要调整列顺序，有哪些可落地的替代方案
优先放弃“必须物理顺序一致”的执念。SQL 查询不依赖字段定义顺序，SELECT * 的返回列序由表定义决定，但显式写出字段名（如 SELECT name, age, id）完全可控，应用层无需感知物理布局。
- 若为兼容旧 ORM 或导出工具而需调整，用
pt-online-schema-change或gh-ost在线迁移，避免主从延迟和长锁 - 若表极小（innodb_fast_shutdown=0 后再执行
COPY类 DDL - 禁止在从库执行；主库执行前先
STOP SLAVE;，完后再START SLAVE;，防复制中断 - 用
SELECT COUNT(*) * AVG_ROW_LENGTH预估拷贝量，比凭感觉更可靠
列顺序是物理实现细节，不是逻辑契约。越早接受“应用层适配字段名而非位置”，越少掉进 AFTER 带来的锁表陷阱。
