mysql 8.0.19+ 中 add column ... after 被静默忽略，字段始终加到末尾；仅 modify/change column 支持 after/first，但必须完整重写字段定义（含类型、约束、默认值、注释），否则会丢失原有属性。
MySQL 8.0.19+ 中 ADD COLUMN ... AFTER 已被静默忽略，字段顺序只能靠 MODIFY COLUMN 或 CHANGE COLUMN 配合完整字段定义来调整；不写全约束、默认值、注释等，就会丢属性。
为什么 ALTER TABLE ... ADD COLUMN c INT AFTER c1 没效果？
这不是你写错了，是 MySQL 官方从 8.0.19 版本起改了行为：语法保留，执行时直接跳过 AFTER 和 FIRST，不报错、不警告、也不生效。你跑完再 DESCRIBE t1，新字段永远在末尾。
- 只影响
ADD COLUMN，MODIFY/CHANGE仍支持AFTER/FIRST - MySQL 5.7、8.0.18 及更早版本仍正常工作
- MariaDB 10.5+ 全支持（含
ADD） - 确认当前版本：运行
SELECT VERSION()
用 MODIFY COLUMN 移动字段的正确写法
必须显式写出字段的全部定义，否则会覆盖原设置。比如原字段是：
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
想把它移到 name 后面，就得这样写：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
ALTER TABLE users MODIFY COLUMN created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' AFTER name;
- 漏掉
NOT NULL？字段变成允许 NULL - 漏掉
COMMENT？注释清空 - 漏掉
DEFAULT CURRENT_TIMESTAMP？默认值丢失 - 查原始定义最稳妥方式：
SHOW CREATE TABLE users，复制对应字段那一行再改位置
多个字段要重排，或带外键/主键/生成列怎么办？
MySQL 不支持单条语句调多个字段位置，也不能直接对主键字段用 AFTER —— 会报错。
- 有主键/唯一约束？先
DROP PRIMARY KEY（注意备份原定义），改完再加回 - 字段是外键？得先
DROP FOREIGN KEY fk_name，调整完再ADD CONSTRAINT - 字段参与生成列、虚拟列或函数索引？调整顺序可能触发隐式表重建，大表要预估锁时间和磁盘空间
- 多字段重排？只能分步执行，且每次都要基于最新顺序写目标位置（比如先移 A，再移 B 时，A 已不在原位）
什么时候该放弃 ALTER，直接重建表？
当表数据量大、字段多、约束复杂，或者你正从 5.7 升级到 8.0.25 后反复试 MODIFY 出错时，重建反而更安全可控。
- 步骤：建新表（按目标顺序 + 完整约束/索引/注释）→
INSERT INTO new SELECT *→RENAME TABLE - 但注意：
SELECT *会丢自增当前值、触发器、分区定义、隐藏列（INVISIBLE）、COLLATION 细节 - 起点一定是
SHOW CREATE TABLE old，手动补全所有元信息 - 线上操作前，务必确认应用没硬编码字段下标（如 JDBC 里用
rs.getInt(2)）
字段顺序本身不影响查询性能，但一旦动，就牵扯约束完整性、应用兼容性和备份恢复逻辑——最容易被忽略的是注释和默认值的“静默丢失”，不是改不动，而是改得不全。
