17370845950

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、后端、测试、甚至前端（如果涉及状态映射）都要对齐字段含义和生命周期。每次变更留好回滚路径，比追求“一步到位”更重要。