MySQL 8.0.19起AFTER/FIRST被静默忽略，字段始终追加至末尾；如需中间位置，须重建表或用视图隐藏物理顺序。
MySQL 添加字段时用 AFTER 指定位置，只在部分版本有效
MySQL 8.0.19 之前，AFTER 确实能控制新字段插入到某列之后；但从 8.0.19 开始，官方明确移除了对 AFTER 和 FIRST 的支持（仅保留语法兼容，实际被忽略）。这意味着：你写了 AFTER col_x，字段仍会加到表末尾，且不报错——容易误以为成功了。
常见错误现象：ALTER TABLE t1 ADD COLUMN c2 INT AFTER c1; 执行无报错，但查 DESCRIBE t1; 发现 c2 并没排在 c1 后面。
- MySQL 5.7 / 8.0.18 及更早：支持
AFTER，行为符合预期 - MySQL 8.0.19+：语法保留但被静默忽略，字段始终追加到末尾
- MariaDB 10.5+：仍完整支持
AFTER和FIRST
想真正控制列顺序，只能重建表
MySQL 原生不提供“重排现有字段顺序”的命令。要让新字段出现在中间，必须用 CREATE TABLE ... SELECT 或 ALTER TABLE ... ALGORITHM=INPLACE 配合全字段显式声明——本质是重建表结构。
典型做法是导出建表语句，手动调整字段顺序，再执行：
CREATE TABLE t1_new ( id INT, name VARCHAR(50), new_col VARCHAR(20) COMMENT '我要插在这里', age INT ) ENGINE=InnoDB;
然后迁移数据并重命名：
INSERT INTO t1_new (id, name, age) SELECT id, name, age FROM t1;DROP TABLE t1;RENAME TABLE t1_new TO t1;
注意：该操作会锁表（尤其大表），生产环境务必评估停机窗口；若启用了 innodb_file_per_table，重建后还能释放碎片空间。
为什么 MySQL 要废弃 AFTER？
核心原因是存储引擎层（InnoDB）本身不维护“逻辑列序”概念，字段顺序只影响行格式解析和客户端展示，对查询性能、索引、约束均无实质影响。MySQL 认为强制维护列序增加了不必要的实现复杂度和兼容性负担。
实际影响包括：
- ORM 工具（如 Django、SQLAlchemy）通常按建表顺序映射字段，列序变化可能导致
SELECT *结果列偏移 - 某些 ETL 工具依赖固定列位置做字段匹配，顺序错乱会引发导入失败
-
mysqldump --skip-extended-insert输出的 INSERT 语句依赖列序，重建表时需同步更新下游解析逻辑
替代方案：用视图隐藏物理顺序
如果只是希望应用层看到特定字段顺序，而不想动底层表结构，定义视图是最轻量的选择：
CREATE VIEW v_t1 AS SELECT id, name, new_col, age FROM t1;
这样应用查 v_t1 就能得到想要的列序，且无需锁表或迁移数据。
但要注意：视图不能直接用于所有 DML 场景（比如含聚合或多表 JOIN 的视图不可更新），且每次查询都会重解析底层表——对高频小查询几乎无开销，但对复杂聚合可能有轻微延迟。
列序这件事，本质是人对结构的感知需求，不是数据库的运行必需。真要改，得接受重建成本；想绕过，视图比硬调物理顺序更可持续。
