低版本项目 SQL
补升级操作指南

先记住这条主线

开始前准备

请先准备并填写下面 7 项。填不全就停在这里：

• 当前任务已经明确授权对这个数据库写入。
• 大表变更的锁表、重建、磁盘增长和预计耗时已经评估。
• SQL 中没有未评审的 DROP、TRUNCATE、无条件 DELETE 或无条件 UPDATE。
• SQL 文件中没有账号、口令、Token、客户个人数据。

1. 在 DBeaver 打开 data_center 数据库。
2. 打开表 ydy_pipeline_log。
3. 找到 build_business 列，按项目标识筛选：build_business LIKE '%你的项目标识%'。

将 id 按降序排列，最大的 id 放在第一行，再读取第一行的 build_version。

也可以执行只读查询

SELECT id, build_version, build_business, build_time
FROM data_center.ydy_pipeline_log
WHERE build_business LIKE '%你的项目标识%'
ORDER BY id DESC
LIMIT 1;

当前部署版本：__________
最新发布记录 ID：__________
发布时间：__________

进入正确的业务代码仓库，例如 store。先检查工作区：

git status --short --branch
git remote -v
git branch --show-current

只有工作区干净、远程地址正确、当前分支正确时，才继续：

git fetch origin --prune --tags
git switch master
git pull --ff-only origin master
git rev-parse HEAD
git rev-parse origin/master

• 两个 SHA 完全相同：本地 master 已和远程一致。
• 两个 SHA 不同：不要开始比对；先让研发按仓库 Git 流程处理。
• git status 有本地修改：不要删除、覆盖或强行切换；先找修改人确认。

假设步骤 1 查到 V2.37.17，先确认 Tag 存在：

git tag -l 'V2.37.17'
git show -s --format='%H %ci %s' V2.37.17
git checkout V2.37.17

看完返回：

git switch master

升级起点来自发布日志，升级终点来自本次发布单或负责人批准。不要把“远程最新提交”自动当作升级终点。

当前部署 Tag：__________
本次目标 Tag：__________
目标 Tag 审批来源：__________

git show -s --format='%H %ci %s' <本次目标Tag>

编辑器支持分支比较

选中项目目录，依次点击 Git → Compare with Branch...，选择本次目标 Tag。

重点检查版本 SQL、db/config.sql、db/menu.sql，以及项目明确约定的初始化或迁移 SQL。

编辑器不支持时

git diff --name-status <当前部署Tag>..<本次目标Tag> -- ':(glob)db/**/*.sql' 'db/*.sql'
git log --reverse --oneline <当前部署Tag>..<本次目标Tag> -- db
git diff <当前部署Tag>..<本次目标Tag> -- db/config.sql db/menu.sql

• APPLIED：目标结构或数据已存在，跳过执行，但仍回读。
• NOT_APPLIED：前置条件满足，可以进入执行清单。
• PARTIAL_OR_CONFLICT：新旧结构混合或只执行了一部分，立即停止。

SELECT DATABASE() AS current_database, VERSION() AS database_version;

再按本次 SQL 补充表、字段、索引、数据数量、重复和悬空记录检查。

目标数据库：__________
数据库版本：__________
升级 SQL 文件：__________
SQL SHA-256：__________
备份或恢复点：__________
执行窗口：__________

shasum -a 256 <升级SQL文件>

适合少量配置、菜单或单个结构变更，并且每条语句都能单独回读。

1. 在 DBeaver 选择正确数据库连接。
2. 点击 SQL Editor → Open SQL console。
3. 粘贴复核后的 SQL，并按 01、02、03 分段。
4. 每次只选中一个编号步骤，确认选区从正确语句开始。
5. 执行后立刻运行该步骤的回读 SQL，通过后才进入下一步。

适合已经由研发整理成单个有顺序、可复核、可回读的升级脚本。

1. 确认脚本只包含当前 Tag 到目标 Tag 的 SQL。
2. 确认编码、语句顺序、分隔符和目标数据库。
3. 右键目标数据库，点击 Tools → Execute script。
4. 选择已经复核并计算校验和的 SQL 文件。
5. 记录开始时间、结束时间、返回结果和影响行数。
6. 脚本结束后逐项执行 postcheck，不能只看“执行成功”。

只有本次发布修改了消费、订单处理、队列消费者或 Work 常驻进程会加载的相关代码时，才执行本步骤。如果只执行 SQL、没有发布消费相关代码，直接跳过。

执行前确认

• 已进入正确的应用服务器，并使用获批的运维账号。
• 发布负责人已确认需要重启 Work，维护窗口和业务影响已通知。
• 已记录目标 Work 的 Supervisor 进程名或进程组；不要根据相似名称猜测。
• 已评估正在处理的任务是否会中断、重复消费或漏消费。

如果发布流程已经批准“重新加载 Supervisor 配置并完整重启 supervisord”，按下面顺序执行：

supervisorctl status
supervisorctl update
supervisorctl reload
supervisorctl status

1. 第一次 status：保存所有进程的重启前状态。
2. update：重新读取配置，新增或删除配置项，并重启受配置变更影响的程序；报错时立即停止，不要继续 reload。
3. reload：重启 supervisord，可能停止并重新启动它管理的全部进程，不是只重启一个 Work。没有整组重启授权时不要执行。
4. 最后一次 status：确认目标 Work 为 RUNNING，并检查没有新的 FATAL、BACKOFF、EXITED 或异常 STOPPED。

命令语义参考：Supervisor 官方 supervisorctl Actions 文档。现场仍以项目实际 Supervisor 版本和发布规范为准。

是否修改消费相关代码：是 / 否
重启范围与审批人：__________
重启前状态：__________
重启后状态：__________
异常日志或负责人：__________

失败立即停止，按当前状态续跑

1. 立即停止，不继续后面的语句。
2. 保存失败语句、错误码、错误消息和时间。
3. 重新查询当前表、字段、索引和相关数据。
4. 标出已完成、未执行和部分状态。
5. 让研发根据当前真实状态给出“下一条获批操作”。

升级后验收

完成不等于“SQL 没报错”。必须分别记录三个状态：

SQL 执行：通过 / 失败 / 部分完成
数据库验收：通过 / 失败 / 待验证
业务冒烟：通过 / 失败 / 未授权执行
执行人：__________
复核人：__________
剩余风险与负责人：__________

一页操作检查表

执行前

• 项目、环境、数据库、当前 Tag、目标 Tag 已确认。
• 本地 master 与 origin/master 一致。
• 当前 Tag 到目标 Tag 的 SQL 差异已经复核。
• 每条 SQL 都有编号、依赖、期望结果和回读 SQL。
• SQL 文件 SHA-256 已记录。
• 备份或恢复点可用。
• 生产写入授权覆盖本次 SQL 和数据库。

执行中

• SELECT DATABASE() 与批准目标一致。
• 当前选区或脚本从正确编号开始。
• 每一步执行后都回读。
• 结果、影响行数和时间已记录。
• 首个异常出现后已停止。

执行后

• 结构和数据 postcheck 通过。
• 重复、悬空和业务不变量检查通过。
• 若修改了消费相关代码，Work 已按批准范围重启且状态为 RUNNING；仅执行 SQL 时已标记“不适用”。
• 原页面或 API 问题消失。
• 最小业务冒烟通过，或明确记录“未授权执行”。
• SQL_EXECUTED、SQL_VERIFIED、BUSINESS_SMOKE_PASSED 分开记录。

常见问题