mysql 8.0.19+ 中 add column 的 after/first 被静默忽略，字段始终加到末尾；modify/change column 中仍有效，但需完整重写字段定义，否则丢失属性。
MySQL 8.0.19 及之后版本中，AFTER 和 FIRST 在 ADD COLUMN 里已被静默忽略，字段始终加到末尾；但 MODIFY COLUMN 或 CHANGE COLUMN 中仍可生效——前提是必须完整重写字段定义。
为什么 ALTER TABLE ... ADD COLUMN ... AFTER 不起作用？
这是 MySQL 官方在 8.0.19 版本做的行为变更：语法保留，但执行时直接忽略 AFTER 和 FIRST，不报错也不生效。你执行完 ALTER TABLE t1 ADD COLUMN c2 INT AFTER c1，再 DESCRIBE t1，会发现 c2 始终排在最后。
- 只影响
ADD COLUMN，不影响MODIFY/CHANGE - MySQL 5.7、8.0.18 及更早版本仍正常支持
- MariaDB 10.5+ 仍完整支持
AFTER/FIRST（含ADD） - 检查当前版本：运行
SELECT VERSION()
MODIFY COLUMN 调整顺序的正确写法
用 MODIFY COLUMN 移动已有字段时，AFTER/FIRST 依然有效，但必须显式写出字段的完整定义（类型、约束、默认值、注释等），否则会丢失原属性。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 原字段是
c DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' - 想把它移到
a后面，就得写：ALTER TABLE t1 MODIFY COLUMN c DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' AFTER a - 漏掉
NOT NULL？字段变成允许 NULL - 漏掉
COMMENT？注释被清空 - 字段有主键/唯一约束？需先
DROP PRIMARY KEY再操作，否则报错
CHANGE COLUMN 和 MODIFY COLUMN 的关键区别
两者都能调顺序，但语义和使用成本不同：
-
CHANGE COLUMN必须写“旧名 新名”，即使不改名也要重复写一遍：CHANGE COLUMN c c DATETIME ... AFTER a -
MODIFY COLUMN不允许改名，只改定义和位置，写法稍简洁 - 如果字段参与生成列、虚拟列或函数索引，调整顺序可能触发隐式表重建，大表要预估锁时间和磁盘空间
- 外键字段不能直接用
AFTER移动，需先DROP FOREIGN KEY，调整完再加回
替代方案：什么时候该放弃 ALTER，改用重建？
当表很大、字段多、约束复杂，或你正在跨版本迁移（比如从 5.7 升级到 8.0.25），反复试 MODIFY 容易出错且耗时，不如用安全可控的方式重建：
- 创建新表，按目标顺序定义所有字段（含完整约束、索引、注释）
INSERT INTO new_table SELECT * FROM old_table- 原子性重命名：
RENAME TABLE old_table TO backup, new_table TO old_table - 注意：自增 ID、触发器、分区定义需手动迁移，
SHOW CREATE TABLE是起点
物理字段顺序对查询性能几乎无影响，真正重要的是索引设计和 WHERE 条件匹配度。别为“看着顺眼”硬调顺序，尤其在线上大表上——容易卡住 DML，也容易丢约束。
