SQL Server存储过程变更不能只靠ALTER PROCEDURE，因其不保留历史版本、无法自动回滚；应采用“单对象单文件+CREATE OR ALTER+Git标签+SHA2_256校验”方式实现可追溯、原子化、可验证的版本管理。
SQL Server存储过程变更为什么不能只靠ALTER PROCEDURE
因为 ALTER PROCEDURE 只更新定义，不保留历史版本，也没法自动还原到某次提交前的状态。一旦改错、上线异常或被误覆盖，只能从备份或开发环境里手动捞脚本——这在多环境、多人协作时极不可靠。
真正可控的回滚，依赖的是「可追溯的、原子化的 DDL 脚本」+「版本控制系统」，而不是数据库里的实时对象状态。
怎么组织Git仓库里的存储过程脚本才方便回滚
关键不是把整个数据库导出扔进 Git，而是按「单对象、单文件、带元数据」方式管理：
-
procs/usp_GetUserById.sql：每个存储过程一个文件，文件名即对象名（含 schema） - 文件头部加注释块，包含：
-- version: 1.2.0、-- author: @zhang、-- created: 2024-05-12、-- depends_on: dbo.Users - 所有脚本以
CREATE OR ALTER PROCEDURE开头（SQL Server 2016+），避免首次部署时CREATE报“对象已存在”错误 - 禁止在脚本中写
DROP PROCEDURE+CREATE PROCEDURE组合——它会清空执行计划缓存，且无法保证原子性
用Git标签做版本锚点，回滚就等于检出+重部署
每次上线前打轻量标签，比如 v2.3.1-prod，对应一组通过测试的 procs/*.sql 文件。回滚时不是“撤销某次 commit”，而是：
github-repo-analyzer
下载
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
- 执行
git checkout v2.2.0-prod - 用 SQLCMD 或 PowerShell 遍历执行当前目录下所有
procs/*.sql（顺序无关，因每个都是CREATE OR ALTER） - 验证
sys.procedures中modify_date是否批量更新为当前时间
注意：如果过程中有新增参数、删除列等不兼容变更，光靠脚本回滚不够，还需同步检查应用层调用是否适配——Git 管的是 DDL，不是业务契约。
自动化部署脚本里必须校验 checksum 防止静默失败
直接 sqlcmd -i *.sql 很危险：某个脚本语法错、权限不足或被意外截断，可能只执行了一半就停了，而返回码仍是 0。必须加一层防护：
- 部署前对每个
.sql文件计算 SHA2_256，存入deploy_manifest.json - 部署后查
sys.sql_modules，用HASHBYTES('SHA2_256', definition)对比实际内容 - 发现任一不匹配，立即中断并报错：
Checksum mismatch for dbo.usp_UpdateOrderStatus
没有这个校验，你永远不知道数据库里的存储过程是不是真的和 Git 里的一致——尤其当有人绕过 Git 直接在生产库上改了 ALTER PROCEDURE。
