CI/CD中如何实现按版本筛选的SQL脚本自动化执行？

基于现有--v0.xxx版本标注规则的实现方案 #

这套方案完全适配你当前的SQL文件编写规则，不需要调整现有脚本格式，落地步骤如下：

• 第一步：在所有需要发布的目标数据库中，提前创建一张 schema 变更记录表，表名可以定为DB_SCHEMA_CHANGE_LOG，核心字段包含：
  • sql_file_name：记录执行的SQL文件名，比如alter_tables.sql
  • version_tag：记录执行的增量版本标识，比如v0.1、v0.2
  • exec_time：脚本执行时间
  • exec_status：执行结果（成功/失败）
  • trigger_source：触发执行的CI任务ID/操作人
    这张表是所有环境的变更唯一可信源，用来判断哪些增量已经在当前环境执行过。
• 第二步：开发一个轻量的SQL解析执行组件，可以用Python、Shell或者你们团队熟悉的语言开发，核心逻辑：
  1. 遍历发布包中所有后缀为.sql的文件，逐行扫描
  2. 识别单独成行、行首匹配--v<版本号>格式的行作为版本分隔标记（加这个规则是为了避免把SQL内部的普通注释误判为版本标记）
  3. 把每个版本标记和它下方直到下一个版本标记/文件末尾之间的SQL语句做绑定，最终形成「SQL文件名+版本号+对应可执行SQL块」的映射集合
• 第三步：把组件集成到现有CI/CD流程中，作为数据库发布节点的执行逻辑，执行流程固定为：
  1. 连接目标环境数据库，查询DB_SCHEMA_CHANGE_LOG，拉取当前环境已经执行成功的所有（文件名+版本号）组合
  2. 接收本次发布传入的目标执行版本清单（比如你举的场景就是alter_tables.sql:v0.2），先做两层校验：如果目标版本已经存在执行成功的记录，直接跳过避免重复执行；如果目标版本依赖的前置版本未执行（比如要跑v0.2但查不到v0.1的成功记录），直接中断流程抛出校验错误
  3. 从解析好的映射集合中取出对应版本的SQL块，开启事务执行：执行成功就提交事务，同时往DB_SCHEMA_CHANGE_LOG插入对应版本的成功记录；执行失败就整体回滚，记录错误日志中断发布

对应你提到的ABC环境场景：流程启动后查询日志，确认create_tables.sql全量变更、alter_tables.sql的v0.1已经执行完成，本次传入的目标版本是v0.2，校验前置依赖满足，就只会提取--v0.2标记下到--v0.3标记前的两段ALTER语句加COMMIT执行，完全不会触碰v0.1、v0.3对应的SQL内容，符合发布要求。

更优的替代解决方案 #

你当前用单文件堆叠多版本增量的方式，长期维护会出现文件越来越大、多人协作改同一个文件容易产生合并冲突、解析逻辑容易出bug的问题，生产环境更推荐用下面两种成熟方案：

• 方案1：拆分单文件为独立版本脚本
  把原来塞在同一个SQL文件里的不同版本增量，拆成独立的SQL文件，按版本号做目录或者文件名命名，比如按如下结构存放：

  sql/
    v0.1__modify_employee_firstname_len.sql
    v0.2__set_employee_name_notnull.sql
    v0.3__add_employee_email.sql
  

  这种模式下不需要做复杂的文件内语句块切割，只要按版本号排序，对比变更日志表中已经执行过的文件，按顺序执行未上线的脚本即可，逻辑更简单，也能彻底解决多人协作的文件合并冲突问题。
• 方案2：使用成熟的开源数据库版本控制工具
  不需要自己开发解析、执行、日志记录的逻辑，直接用行业通用的工具比如Flyway、Liquibase即可，这类工具原生支持：
  • 自动维护版本变更日志表
  • 自动识别未执行的增量脚本，按版本顺序执行
  • 执行失败自动回滚
  • 多类型数据库兼容（Oracle、MySQL、PostgreSQL等都支持）
  • 预执行检查、回滚脚本配置等进阶能力
    稳定性比自研脚本高很多，只需要按照工具要求的命名规范存放SQL文件即可，接入成本很低。

不管用哪种方案，都建议在发布流程中加预检查环节：所有SQL脚本先在测试环境执行验证通过，再往生产环境发布，避免语法错误、锁表等问题影响线上业务。

内容的提问来源于stack exchange，提问作者Ranjeet