加列的位置与代价
给已有表加列，两种数据库的写法差别不大，但不是完全一样：MySQL 支持指定新列插在某一列之后，PostgreSQL 只能追加到末尾，列顺序由创建顺序决定。位置不只是审美问题——MySQL 把列插到中间可能触发整表重建，大表上代价远超追加到末尾。另外，依赖查询结果列位置的下游脚本在加列后会出现取值错位，这是加列引发的另一类故障。
基本信息
| 适用平台 | MySQL 8.0 / PostgreSQL 12 及以上 |
|---|---|
| MySQL 位置 | 可用关键字指定插在第一列或某列之后 |
| PostgreSQL 位置 | 只能追加到末尾，列顺序不可变 |
| 低成本场景 | 加可空列或带常量默认值的列通常是轻量操作 |
| 下游影响 | 按位置解析结果的脚本会在加列后错位 |
典型使用场景
- 业务新增字段：给用户表加昵称、给订单表加渠道来源
- 灰度兼容：先加可空列上线，业务双写稳定后再收敛
- 拆表前的准备：把待迁移字段先补齐到目标表
- 修复加列引发的解析错误：把下游脚本改成按列名取值
- 评估大表加列的执行窗口
两库写法
两库写法
-- MySQL：指定插在 name 之后
ALTER TABLE users ADD COLUMN nickname VARCHAR(50) NULL AFTER name;
-- MySQL：也可以插到第一列
-- ALTER TABLE users ADD COLUMN remark VARCHAR(100) NULL FIRST;
-- PostgreSQL：只能追加到末尾
ALTER TABLE users ADD COLUMN nickname varchar(50);
-- 列顺序固定为创建顺序，展示顺序交给查询的列清单
-- 确认列的最终位置与定义
-- MySQL：SHOW CREATE TABLE users;
-- PostgreSQL：查询 information_schema.columns 的 ordinal_position
-- 让下游脚本按列名取值，而不是按位置
-- 导出与分析脚本里显式写出列清单关注点对照
| 关注点 | MySQL | PostgreSQL |
|---|---|---|
| 指定位置 | 支持插到中间或第一列 | 只能追加到末尾 |
| 插到末尾的成本 | 较低 | 较低 |
| 插到中间的成本 | 可能触发表重建 | 不适用 |
| 常量默认值 | 加列成本可控 | 较新版本支持快速默认值 |
| 结果列顺序 | 随实际列顺序 | 随实际列顺序，末尾追加 |
加列本身的成本通常不高，风险更多来自它引发的连锁：下游按位置解析的脚本错位、大批量写入时的字段映射、数据同步任务的列清单。上线前把这几处一起检查。
给大表加一个带默认值的列时，较新版本可以避免重写整表，旧版本则可能整表重写。执行窗口要结合版本与数据量评估，不要假设所有加列都很轻。