存储过程不能直接灰度发布，必须靠版本命名（如sp_calc_v1/sp_calc_v2）+应用配置路由实现；禁止drop/create切换，须校验参数兼容性、执行计划及结果结构，并确保调用链契约一致。
存储过程不能直接灰度发布，必须靠版本命名+调用路由
SQL 存储过程没有内置的“灰度开关”或 CREATE OR REPLACE PROCEDURE IF NOT EXISTS WITH GRAYSCALE = true 这类语法。所谓灰度，本质是让新旧逻辑共存、由上层控制调用路径。硬删旧过程再建新过程（DROP PROCEDURE + CREATE PROCEDURE）会引发正在执行的事务失败、连接中断、监控告警误报等问题。
可行做法是显式带版本后缀命名，例如原过程叫 sp_calculate_user_score，灰度期同时存在：sp_calculate_user_score_v1 和 sp_calculate_user_score_v2。
- 应用配置中统一管理过程别名映射，如 YAML 里写
proc_alias: sp_calculate_user_score_v2，代码拼 SQL 时动态引用 - 上线前先创建
sp_calculate_user_score_v2，确认语法通过、执行计划稳定、返回结果结构兼容（尤其 OUTPUT 参数类型/顺序） - 灰度期间可并行调用两个版本做结果比对，例如
EXEC sp_calculate_user_score_v1 @uid = 123和EXEC sp_calculate_user_score_v2 @uid = 123，对比输出值或影响行数 - 禁止在 v2 中修改 INPUT/OUTPUT 参数个数或类型，否则调用方不改代码就会报错
Procedure or function 'xxx' expects parameter '@xxx', which was not supplied.
SQL Server 复制场景下，“复制存储过程执行”不是灰度方案
SQL Server 的“复制存储过程执行”（在发布属性中设置为 存储过程的执行 或 在SP 的串行化事务中执行）仅适用于事务复制场景，目的是同步执行动作而非支持灰度。它要求过程必须在可序列化事务中运行，否则退化为 DML 复制；且该机制只作用于订阅端自动重放，不提供版本切换能力。
这种配置容易被误认为“灰度可用”，但实际风险很高：
- 一旦发布端执行了 v2 版本过程，所有订阅端立刻执行相同逻辑，无法按需控制范围
- 若 v2 有 bug，错误逻辑已扩散到全部订阅库，回滚成本远高于应用层路由
- 无法对单个租户、用户 ID 段或时间窗口做灰度验证，违背灰度核心原则
Oracle / OceanBase / 金仓等兼容型数据库的 PL/SQL 灰度陷阱
在 Oracle 兼容数据库（如 OceanBase Oracle Mode、金仓 KES）中，PL/SQL 过程支持包（PACKAGE）、游标、异常块等复杂结构，但灰度时更易踩坑：
- 包体（
BODY）更新不触发包头（SPEC重编译，可能导致依赖它的其他过程失效，报错ORA-04068: existing state of packages has been discarded - 过程内调用的视图或函数若未同步灰度，会出现隐式版本错配——比如
sp_v2调用了未升级的fn_get_config_v1，结果不可预期 - 不同数据库对
CREATE OR REPLACE的原子性处理不一致：Oracle 是原子替换，MySQL 不支持OR REPLACE，金仓部分版本会先删后建，中间存在短暂不可用窗口 - 权限继承问题：新版本过程创建后，默认不继承旧版本的 EXECUTE 权限，需显式
GRANT EXECUTE ON sp_xxx_v2 TO app_user
真正可控的灰度路径：应用层路由 + 数据库侧双版本共存
最稳妥的灰度落地方式，是把决策权交给应用，数据库只负责提供稳定、隔离的多版本对象：
- 应用启动时加载配置，决定当前流量走
sp_xxx_v1还是sp_xxx_v2；可基于请求 Header、用户 ID 哈希、租户 ID 等字段动态路由 - 数据库中两个版本过程完全独立，互不覆盖、互不影响；v1 可长期保留，直到确认 v2 全量稳定
- 配合全链路灰度框架（如 OpenSergo），在网关层打标
gray=true，下游服务透传，最终 JDBC 层根据标选择调用哪个过程名 - 关键点：所有调用必须使用全限定名，如
EXEC mydb.dbo.sp_calculate_user_score_v2，避免 schema 搜索路径（search_path）导致行为漂移
容易被忽略的是：存储过程灰度不是“换一个名字就行”，它牵扯调用链上下游的契约一致性。哪怕只是改一行计算逻辑，也要确保输入参数语义、输出格式、错误码含义、事务边界全部对齐——否则灰度切流那一刻，就是线上故障开始的时间点。
