在分布式数据库环境下SQL存储过程的适配方案是什么？
SQL Server存储过程迁移到分布式数据库需彻底重构：剥离单机语义（如@@ROWCOUNT、SET TRANSACTION）、禁用四部分命名与环境推断，改用显式参数；放弃分布式事务，采用本地消息表+异步补偿；方言逻辑抽离为独立SQL文件按库加载；所有标识符强制小写加下划线。
SQL Server 存储过程迁移到分布式数据库时，不能直接运行
金仓等国产分布式数据库虽提供 T-SQL 兼容层，但仅覆盖语法层面（如 TOP、IDENTITY、PIVOT），不保证执行语义完全一致。尤其涉及事务控制、锁行为、执行计划缓存等底层机制时，原存储过程很可能在分布式环境下返回错误结果或性能断崖式下降。
常见错误现象包括：Msg 7395（事务未升级）、Could not find stored procedure 'xp_cmdshell'（调用被禁用扩展）、或看似成功但跨分片数据不一致。根本原因在于：分布式数据库的事务模型（如两阶段提交或最终一致性）与 SQL Server 的单机强事务模型存在本质差异。
- 必须剥离所有依赖单机语义的逻辑，例如
@@ROWCOUNT、SET TRANSACTION ISOLATION LEVEL在分片间无法全局生效 - 避免使用
SELECT INTO或隐式建表，分布式环境下表元数据可能跨节点不一致 - 禁止在存储过程中硬编码四部分命名（如
[srv_link].db.schema.table），链接服务器在分布式架构中不存在对应概念
环境变量和配置读取必须统一为参数传入
SQL Server 常用 SERVERPROPERTY('MachineName') 或查询系统视图判断环境，这种做法在容器化、多租户、蓝绿发布的分布式环境中完全失效。MySQL 和 PostgreSQL 同样不支持运行时环境变量注入，靠 @@hostname 或 current_setting() 推断环境极易出错。
唯一可靠路径是：所有环境标识（'dev'、'prod'）必须由应用层作为显式参数传入，存储过程内部不做任何推断。
- SQL Server 示例：改为
CREATE PROCEDURE usp_process_order @p_env NVARCHAR(10)，开头校验IF @p_env NOT IN ('dev','prod') ... - MySQL 示例：强制声明
IN p_env VARCHAR(10)，禁用SET @env = IFNULL(@env, 'dev')这类兜底写法 - PostgreSQL 示例：放弃
current_setting('app.env')，改用函数参数env TEXT DEFAULT 'dev'并显式传入
跨库/跨分片操作必须放弃分布式事务，改用最终一致性方案
SQL Server 的 BEGIN DISTRIBUTED TRANSACTION 依赖 MSDTC，在分布式数据库中无对应组件。即使强行模拟，也会因网络分区、节点故障导致事务悬挂或静默降级，引发数据不一致。
真实可行的做法是接受“短暂不一致”，用本地消息表 + 异步补偿替代两阶段提交。
- 在业务库中建
outbox_message表，字段含event_type、payload、status、created_at - 主流程在同一个本地事务中写业务数据 + 插入消息记录（
status = 'pending'） - 独立投递服务轮询该表，将消息发往 Kafka/RocketMQ；下游消费后更新
status = 'sent' - 所有跨分片写操作都走这个通道，不再尝试在存储过程中发起远程 DML
方言逻辑必须抽离到独立 SQL 文件并按数据库类型加载
试图在单个存储过程中用 IF @@VERSION LIKE '%PostgreSQL%' 判断数据库类型，既不可测也不符合分层原则。分布式数据库往往混合部署（如核心交易用金仓，报表用 PostgreSQL），同一套 SQL 需适配多种后端。
正确做法是把非标准逻辑（如分页、UUID 生成、时间函数）全部拆出，按目标数据库命名，由应用配置决定加载哪一份。
- 例如：分页逻辑分别存为
limit_offset_sqlserver.sql、limit_offset_postgres.sql、limit_offset_kingbase.sql - UUID 生成统一用
gen_random_uuid()（PostgreSQL）、NEWID()（SQL Server）、sys_guid()（Oracle）——但这些函数名本身不能出现在通用存储过程中 - 所有标识符（表名、列名、参数名）强制小写 + 下划线，禁用
@param、双引号包裹、大小写混用等方言特性
