不能直接用 create or replace procedure 做灰度，因其会引发调用中重编译报错、ddl排他锁阻塞并发、新旧逻辑无隔离三类问题；应采用版本化命名（如_v1/_v2）加应用层路由实现。
CREATE OR REPLACE PROCEDURE 不能直接灰度发布，必须靠版本化命名 + 应用层路由实现。Oracle、SQL Server、MySQL 等主流数据库均不支持“带灰度状态的存储过程”语法，也没有内置的版本切换开关。
为什么不能直接用 CREATE OR REPLACE PROCEDURE 做灰度？
看似能覆盖旧定义，实际会引发三类问题：
• 调用中过程被重编译，触发 ORA-04068（包状态丢失）或 ORA-04065（依赖失效），下游服务报错
• DDL 操作持有排他锁，阻塞并发读写，高峰期易引发超时雪崩
• 新旧逻辑共存时无隔离机制，无法控制“哪些用户/请求走新版本”
推荐做法：用带版本后缀的存储过程名 + 应用配置路由
核心是把版本信息显式编码进对象名，例如原过程叫 calculate_order_total，灰度期同时存在：
• calculate_order_total_v1（当前生产版）
• calculate_order_total_v2（新逻辑版）
- 应用代码里不硬编码过程名，而是通过配置项（如 Spring Boot 的
app.procedure.version=v2）动态拼接调用 - 上线前先
CREATE OR REPLACE PROCEDURE calculate_order_total_v2 AS ...，确认语法正确、执行计划合理、输入输出参数兼容 - 灰度期间让部分实例（如 K8s 标签为
gray:true的 Pod）调用v2，其余仍调用v1 - 禁止在
v2中修改输入/输出参数类型或数量——否则v1调用方会因签名不匹配而失败
SQL Server 和 Oracle 的关键差异点
SQL Server 允许同名过程在不同 schema 下共存（如 dbo.calculate_order_total 和 gray.calculate_order_total），但需注意：
• 必须用完全限定名调用，否则默认走 dbo
• EXEC gray.calculate_order_total 不能被缓存计划自动复用，可能增加编译开销
Oracle 则更依赖包（package）封装，推荐将过程放入版本化包中：
• pkg_order_v1.calculate_total
• pkg_order_v2.calculate_total
• 包体变更不会影响已运行会话的包状态，比独立过程更安全
容易被忽略的嵌套依赖风险
如果 calculate_order_total_v2 内部调用了 get_user_discount，而后者又被其他业务过程广泛引用，那么一旦 get_user_discount 更新，v2 可能意外失效——即使你没动过它自己的定义。
每次更新任一被依赖的过程，都得全链路验证：
• 手动检查所有调用它的上层过程是否仍能编译成功
• 在测试库跑 SELECT COUNT(*) FROM user_dependencies WHERE referenced_name = 'GET_USER_DISCOUNT' 找出全部依赖路径
• 灰度期间监控 v2 的调用成功率与错误日志，重点看 PL/SQL 错误码（如 ORA-06508）
