这是金融客户做核心系统信创改造时最容易踩的坑之一——本份分析给出结论、依据、演进路径与销售话术，专为面向银行/证券/保险客户的售前与销售场景定制。
在讨论"该不该用"之前，先理清三件事的差别。
为什么分布式数据库 + 存储过程的组合是"性能毒瘤"？
分布式存储过程的 SQL 散落在多个节点，每条都要走 Raft / Paxos 共识协议，网络往返叠加 → 时延暴增。
典型现象：迁移过来的存储过程跑得比单机慢 5-10 倍。
分布式数据库的核心价值是"加节点就加性能"。但存储过程把逻辑塞进数据库，事务跨多分片时反而拖累整体扩展性 —— 等于"用分布式硬件做单机用法"，浪费架构红利。
存储过程里读写混杂，没法清晰分流到只读副本。
异地多活场景下，逻辑跨机房执行 → 跨地域延迟雪崩。
分布式数据库的存储过程没有成熟调试工具（不像 Oracle PL/SQL 有 SQL Developer）。
出问题时日志散落多个节点，定位排查极痛苦。
现代金融架构主流是"微服务 + 业务在应用层 + 数据库做存储"。存储过程把业务塞进数据库，违背"数据库归数据库，业务归业务"的分层原则——变更 = DDL = 高危操作。
各家分布式数据库的存储过程语法不兼容（TiDB / OceanBase / TDSQL 各搞一套）。
一旦写死 → 想换数据库就要重写所有存储过程。
存储过程不是绝对禁止，分场景判断。
| 使用场景 | 判断 | 说明 |
|---|---|---|
| 极简的事务封装（批量插入 + 简单校验） | ⭐⭐⭐ 可以 | 影响面小，事务边界清晰 |
| 跨表的简单聚合统计 | ⭐⭐ 性能可控时可以 | 需压测验证 |
| 从单机库迁移过来的"过渡期" | ⭐⭐⭐ 短期保留 | 长期必须改造 |
| 复杂业务逻辑 / 跨多表事务 | ❌ 千万别 | 架构债务雪球 |
| 高并发交易路径（如支付核心） | ❌ 性能必崩 | 共识协议放大延迟 |
| 跨分片的复杂 Join + 循环 | ❌ 灾难 | 分布式执行计划崩塌 |
原生分布式 = 不支持，国产兼容派 = 兼容但不推荐。
| 数据库 | 存储过程支持度 | 厂商建议 |
|---|---|---|
| TiDB | 明确不支持 | 把逻辑放应用层 |
| OceanBase | 支持（兼容 Oracle PL/SQL） | 仅建议简单场景 + 迁移过渡 |
| TDSQL（腾讯云） | 部分支持 | 推荐应用层 + DB 只做存储 |
| TDSQL-C / TDSQL-H | 支持但不推荐重度使用 | 同上 |
| GaussDB（华为） | 支持（兼容 PG/Oracle） | 大量金融客户用，但官方也建议简化 |
| PolarDB（阿里） | 支持 | 兼容传统 Oracle 客户 |
| CockroachDB / Spanner | 不支持 | 完全否定 |
老 Oracle 上有几千个存储过程，怎么搬到分布式数据库？建议分三阶段。
用 OceanBase / TDSQL 做 PL/SQL 兼容平移，保留所有存储过程先上线。
识别高频交易路径的存储过程，逐步上移到应用层，重构为微服务调用。
数据库只做存储不做业务，业务逻辑全部上移至应用层。
面对客户技术线 CTO / 数据中心总监时直接套用。
"张总，您这边核心系统从 Oracle 搬到分布式数据库，最大的坑就是存储过程。
我建议分三步走：
1. 第一阶段（迁移过渡期）：用 OceanBase 或 TDSQL 做 PL/SQL 兼容平移 —— 快上线。
2. 第二阶段（性能优化期）：识别高频交易路径的存储过程，逐步上移到应用层 —— 性能提升 5-10 倍。
3. 第三阶段（云原生重构期）：业务全微服务化，数据库只做存储不做业务 —— 真正享受分布式扩展性。
腾讯 TDSQL 在工行、建行、中行的核心改造里就是按这条路径走的，6-18 个月完成存储过程下线。"
传统单机数据库时代，存储过程是"性能加速器"；
分布式数据库时代，存储过程是"性能毒瘤"。
数据库归数据库，业务归业务 —— 这是云原生 + 分布式时代的第一性原理。