SQL数据口径变更须通过版本化设计管理，即每次调整需绑定唯一版本号、物理隔离存储、结构化记录元信息，并支持多版本并行与灰度切换。
SQL数据口径变更必须通过版本化设计来管理，核心是让每次口径调整可追溯、可回滚、可对比。
口径变更必须绑定版本号
所有SQL脚本（尤其是报表、宽表、指标计算逻辑）在提交时强制关联唯一版本标识，例如 v20250520_01 或语义化版本 1.2.0。版本号不是随意命名，需体现时间或迭代序号，并与发布分支/标签同步。避免使用“最新版”“临时版”等模糊表述。
SQL脚本按版本独立存储与执行
不同版本的同一口径SQL应物理隔离：
- 存放在独立目录或Git分支中，如 /sql/metrics/revenue/v1.1.0/ 和 /sql/metrics/revenue/v1.2.0/
- 调度任务明确指定版本路径，不复用通用路径或动态读取“最新SQL”
- 上线前通过版本比对工具检查差异，重点识别 where 条件、join 关系、聚合逻辑、空值处理等口径敏感点
口径元信息需结构化记录
每个版本除SQL代码外，必须配套维护一份轻量元数
据文件（如 YAML/JSON），包含：
- 变更原因：业务规则调整？数据源升级？合规要求？
- 影响范围：涉及哪些报表、下游系统、责任人
- 生效时间：计划执行时间与实际执行时间分开记录
- 验证方式：比对样本ID、关键指标波动阈值、AB测试结论
支持多版本并行与灰度切换
生产环境不追求“一刀切”替换，而是允许新旧口径短期共存：
- 通过配置开关控制调度任务调用哪个版本SQL（如参数 --version=v1.2.0）
- 关键指标输出字段增加版本后缀，如 revenue_v1_1_0 和 revenue_v1_2_0，便于交叉验证
- 灰度期保留双跑日志，自动标记口径偏差超限的数据批次
