MySQL 5.7 的 AFTER 不稳定，MyISAM 忽略、InnoDB 因元数据缓存等问题常失效；仅支持 ADD COLUMN，且要求列名大小写精确匹配；无法移动已有列位置，需重建表；8.0.19+ 后被静默忽略。
MySQL 5.7 的 AFTER 实际支持不稳定
MySQL 5.7 虽然语法上允许 AFTER，但它在很多真实场景下会静默失效或直接报错。比如用 MyISAM 引擎时，AFTER 基本被忽略，新列总追加到末尾；InnoDB 表若带全文索引、生成列、或刚执行过 OPTIMIZE TABLE，元数据缓存可能未刷新，导致位置不生效。你执行成功了，但 DESCRIBE table_name 看到的列序和预期不符——这不是你的 SQL 写错了，是底层行为不可靠。
AFTER 只能用于 ADD COLUMN，且依赖列名精确匹配
它不适用于 MODIFY COLUMN 或 CHANGE COLUMN；AFTER 后面必须跟一个**已存在且大小写完全一致**的列名。Linux 环境下，如果表里实际列名是 user_id，你写成 AFTER User_id 就会触发 ERROR 1054 (42S22): Unknown column 'User_id' in 'after clause'。常见踩坑点包括：
- 拼写错误（比如
creat_at而非created_at） - 多写逗号：
AFTER id,→ 直接语法错误 - 目标列被其他列依赖（如虚拟列引用了它），导致隐式重排失败
真正需要中间列序时，DDL 本身无解
MySQL 原生没有“移动已有列位置”的命令。即使 AFTER 生效，也只是在新增时插一次；想把已存在的列 status 从末尾挪到 email 后面？做不到。唯一办法是重建表：CREATE TABLE new_table AS SELECT ... 显式声明字段顺序，再迁移数据。这个过程锁表、耗资源，5.7 还不支持 ALGORITHM=INPLACE 对所有变更生效，大表操作风险极高。
版本升级反而让 AFTER 更不可信
到了 MySQL 8.0.19+，AFTER 和 FIRST 被官方明确降级为“语法兼容保留，实际静默忽略”——你写了也白写，字段永远加到末尾，还不报错。这意味着：你在 5.7 上靠运气生效的 AFTER，到了 8.0.19+ 就彻底失去意义。依赖它做自动化部署或迁移脚本，很容易在版本升级后突然失效，且难以排查。
列顺序对查询性能、索引、约束都没有影响，MySQL 认为它只是展示层面的事。真要控制物理顺序，得靠建表时一次性写对；后期维护，别指望 AFTER 能兜底。
