紧急回滚无备份存储过程需分数据库处理：SQL Server须从系统视图（如sys.sql_modules）提取当前定义，MySQL 8.0+需用information_schema.ROUTINES查询，且均需提前导出带时间戳和commit ID的脚本并纳入Git管理。
存储过程改了但没留备份，怎么紧急回滚
没有提前备份的存储过程，只能从系统视图里捞历史定义——但 SQL Server 和 MySQL 处理方式完全不同，别直接套用。SQL Server 的 sys.sql_modules 只存当前版本，sys.procedures 也不带历史；MySQL 的 mysql.proc 表在 8.0+ 已废弃，且不记录变更时间。
- 上线前必须导出：用
sp_helptext（SQL Server）或SHOW CREATE PROCEDURE（MySQL）把定义存成文件，命名带上时间戳和 commit ID，比如usp_calculate_fee_20240521_v2.sql - 不要依赖“自动备份”：SSMS 或 Navicat 的自动脚本生成功能默认不包含权限、加密状态、执行上下文（如
EXECUTE AS），漏掉就可能恢复后报The module 'xxx' depends on the missing object 'yyy' - 生产环境禁止用
ALTER PROCEDURE直接改：先DROP PROCEDURE再CREATE PROCEDURE，否则sys.dm_exec_procedure_stats里的执行统计会被清空，影响性能归因
用 Git 管理存储过程脚本时，哪些内容必须一起提交
只提交 CREATE PROCEDURE 语句远远不够。Git 能帮你回滚代码，但不能自动还原依赖对象或权限配置。
- 必须同目录提交：对应
GRANT EXECUTE ON [proc_name] TO [role]、ADD SIGNATURE（如果用了证书签名）、以及该过程引用的用户自定义函数/表值函数的定义脚本 - 避免硬编码数据库名：脚本里写
CREATE PROCEDURE dbo.usp_xxx，而不是CREATE PROCEDURE [MyDB].dbo.usp_xxx，否则迁移测试库时会失败，报错Database 'MyDB' does not exist - 每次提交前跑一次
sqlcmd -S server -d db -i xxx.sql -o out.log 2>&1验证语法，尤其注意 SQL Server 中GO不是 T-SQL 语句，不能出现在动态 SQL 字符串里，否则备份脚本里混入GO会导致Incorrect syntax near 'GO'
回滚脚本执行时报 “There is already an object named 'xxx'”，怎么绕过
这不是权限问题，是恢复逻辑没处理好对象生命周期。直接 CREATE PROCEDURE 必然失败，但盲目加 IF EXISTS DROP 又可能误删其他环境同名但不同用途的过程。
- 安全做法：用
SELECT OBJECT_ID('usp_name', 'P')判断是否存在，存在则用ALTER PROCEDURE替换（保持原有权限和签名），不存在才CREATE - 别信“生成删除脚本”工具：SSMS 右键 → “Script Stored Procedure as” → “DROP and CREATE To” 会把所有权限语句塞进一个事务，而
GRANT在DROP后执行会报Cannot find the object "xxx" - MySQL 用户注意：
CREATE OR REPLACE PROCEDURE是 8.0.20+ 才支持，低版本必须手动判断SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_NAME = 'xxx'，再决定用DROP还是CREATE
自动化备份脚本该抓哪些关键字段
每天凌晨自动导出存储过程，光 dump 定义是废的。缺少上下文信息，三个月后你根本想不起这个过程为什么加了 WITH RECOMPILE。
- 必须附加元数据：用
SELECT create_date, modify_date, is_ms_shipped, is_encrypted从sys.procedures查，并写进同名的.meta.json文件 - 记录调用链：对高频过程，跑一次
SELECT referenced_entity_name FROM sys.dm_sql_referenced_entities('dbo.usp_xxx', 'OBJECT')，输出到.deps.txt，避免回滚后发现下游报表突然查不到数据 - 跳过临时过程：过滤掉
name LIKE '#%'和name LIKE '##%'，它们不在系统视图持久化，备份了也恢复不了
最麻烦的不是技术点，是人——开发改完过程不更新 Git 提交信息，DBA 备份时没校验 checksum，运维恢复时忽略 SET ANSI_NULLS 开关差异。这些地方一漏，脚本再全也没用。
