SQL表结构演进核心是新旧逻辑共存：新增字段应允许NULL并设默认值，语义变更只增不改，拆表用视图过渡，数据迁移需离线+灰度+校验，全程强调协作与回滚。
SQL表结构演进时，核心目标是新增功能不破坏旧数据、不中断线上服务、不强制要求老客户端升级。关键不在“怎么改表”，而在于“如何让新旧逻辑共存”。
字段新增：优先默认值 + 允许NULL
加字段是最常见场景。直接加非空字段会失败（已有行无值），加可空字段又容易在代码里漏判空，引发NPE或逻辑错误。
推荐做法：
- 新加字段设为 允许NULL，同时指定合理默认值（如字符串用
''，数字用0，时间用CURRENT_TIMESTAMP） - 应用层读取时，对NULL做兼容处理（例如：旧数据该字段为NULL → 视为“未启用”或“使用旧规则”）
- 后续通过后台任务批量补全历史数据，等数据齐备再考虑改NOT NULL（需评估业务影响）
字段语义变更：不删不改，只加新字段
比如原status是tinyint表示订单状态（1=待支付，2=已发货），现在要扩展成多状态机且含子状态。硬改枚举值或扩大类型风险高，易导致旧逻辑误判。
更安全的路径：
- 保留原字段，明确其含义不变（如仍只用于前端简略展示）
- 新增字段如
status_v2（JSON或独立状态表ID），承载新状态体系 - 应用层根据版本/配置决定读哪个字段，逐步迁移逻辑
- 旧字段不删除，除非确认所有下游（报表、同步任务、第三方系统）都已下线
拆表与垂直分表：用视图过渡，避免应用直连新表
当单表过大或职责混乱（如用户表混着地址、偏好、风控数据），需拆分。但直接切到新表，所有DAO、SQL、索引都要改，风险集中。
平滑方案：
- 先建新表（如
user_profile），把新字段迁入 - 创建兼容视图
user_full，UNION或JOIN原表+新表，保持原有查询接口不变 - 应用逐步将写操作切到新表，读操作仍走视图；等数据和逻辑稳定后，再引导应用直连新表
- 视图也支持加WHERE条件和简单JOIN，足够覆盖大部分兼容期查询需求
数据迁移：离线+灰度+校验三步走
结构变了，老数据常需转换（如把分散字段合并为JSON，或拆出外键）。不能“ALTER TABLE + UPDATE一把梭”。
稳妥节奏：
- 离线跑批：在低峰期用独立脚本迁移，不锁主表，写入临时表或带版本标记的新字段
- 灰度开关：新逻辑默认关闭，按用户ID段或业务线逐步开启，观察日志和监控
- 双向校验：对同一条记录，比对新旧字段计算结果是否一致（如旧status+time推导出的新state是否匹配）；差异自动告警并落库待查
表结构演进不是技术动作，而是协作过程。DBA、后端、测试、甚至前端（如果涉及状态映射）都要对齐字段含义和生命周期。每次变更留好回滚路径，比追求“一步到位”更重要。
