应使用ANSI SQL标准语法替代数据库特有函数：日期用CURRENT_DATE/CURRENT_TIMESTAMP，字符串截取用SUBSTRING(col FROM start FOR length)，空值判断用IS NULL/IS NOT NULL，类型转换用CAST()，控制结构优先IF...THEN...END IF，建表索引剥离至迁移脚本，临时数据用CTE或派生表，参数用位置参数，返回单结果集并固定列名。
用 ANSI SQL 替代数据库特有函数
不同数据库对字符串、日期、空值的处理差异极大，比如 SUBSTRING() 在 PostgreSQL 里要三个参数，SQL Server 却支持两个；GETDATE() 是 SQL Server 的，PostgreSQL 得用 NOW()。硬写某个库的函数，换环境就报 function does not exist 错误。
实操建议：
- 日期操作统一用
CURRENT_DATE、CURRENT_TIMESTAMP（ANSI 标准），别碰SYSDATE或GETUTCDATE() - 字符串截取用
SUBSTRING(col FROM start FOR length)语法（标准位置式），而非SUBSTRING(col, start, length)（SQL Server/MySQL 风格） - 空值判断只用
IS NULL/IS NOT NULL，避开ISNULL()、NVL()、COALESCE()虽然它被多数支持，但行为细节不一致（如 Oracle 对空字符串和 NULL 不区分） - 类型转换优先用显式
CAST(col AS INTEGER)，少用隐式转换或CONVERT()这类方言函数
避免存储过程体内的非标准控制结构
像 WHILE、LOOP、REPEAT 这些循环语法，各数据库实现差别大：SQL Server 用 WHILE，PostgreSQL 存储过程（PL/pgSQL）用 LOOP 或 FOR，MySQL 用 REPEAT —— 它们不能跨平台复用。
实操建议：
- 能用单条 SQL 解决的，绝不写循环。例如批量更新优先用
UPDATE ... FROM或MERGE（如果目标库支持） - 真需要逐行逻辑时，把循环提到应用层，存储过程只做原子操作
- 如果必须用过程式逻辑，选最通用的
IF ... THEN ... END IF（ANSI/SQL:2003 支持），避开BEGIN TRY ... CATCH（SQL Server）或EXCEPTION WHEN（PL/pgSQL）这类异常块 - 变量声明统一用
DECLARE var_name TYPE形式，并确认目标库是否允许在过程开头集中声明（MySQL 要求严格位置，PostgreSQL 更宽松）
建表与索引语句剥离出存储过程
存储过程不该承担 DDL 职责。像 CREATE TABLE #temp（SQL Server 临时表）、CREATE TEMP TABLE（PostgreSQL）、CREATE GLOBAL TEMPORARY TABLE（Oracle）语法互不兼容，且多数数据库不允许在存储过程中动态执行 DDL（权限/事务限制）。
实操建议：
- 把建表、加索引、设约束等操作单独抽成部署脚本，用迁移工具（如 Flyway/Liquibase）管理，不在存储过程中调用
EXECUTE IMMEDIATE或sp_executesql - 临时数据需求改用 CTE（
WITH子句）或派生表，它们是标准 SQL，兼容性好得多 - 如果必须用临时对象，只用会话级临时表（如 PostgreSQL 的
CREATE TEMP TABLE），并确保调用前检查是否存在（DROP TABLE IF EXISTS要看版本，PostgreSQL 9.2+ 支持，SQL Server 2016+ 才支持）
参数传递与返回值按标准接口设计
SQL Server 用 @param 变量、PostgreSQL 用 $1 位置参数、Oracle 用 :param，连调用方式都不同。更麻烦的是返回结果集：SQL Server 默认允许多结果集，PostgreSQL 函数需声明 RETURNS TABLE 或用 REFCURSOR，MySQL 存储过程只能靠 SELECT 输出。
实操建议：
- 输入参数全用位置参数（
$1,$2），避免命名参数（IN param_name TYPE），后者在跨库适配时解析容易出错 - 返回结果统一用单个结果集，且用明确列名（别依赖
SELECT *），列名和顺序固定，方便 ORM 映射 - 错误信息不依赖
RAISERROR或RAISE EXCEPTION，改用标准 SQLSTATE 码 + 自定义消息字段（如返回表中加error_code和error_msg列） - 避免输出参数（
OUT/OUTPUT），它们在 JDBC/ODBC 层封装差异大，容易丢值或类型错配
真正难的不是写“能跑”的存储过程，而是让同一段逻辑在 PostgreSQL 14、SQL Server 2022、MySQL 8.0 上都返回相同结果——连空字符串比较、小数舍入、时区隐式转换这些细节，都会在某一个库里悄悄翻车。
