SQL Server存储过程用RETURN返回整数状态码最直接，MySQL需用OUT参数替代，PostgreSQL须改写为函数并用SELECT调用。
SQL Server 存储过程中用 RETURN 返回整数状态码最直接
SQL Server 的存储过程默认支持通过 RETURN 语句返回一个 INT 类型的退出码，这是最轻量、最标准的方式。它不依赖输出参数或结果集，调用方（如 C# 的 SqlCommand 或 Python 的 pyodbc）能直接读取 ReturnValue 属性。
注意：这个值不能是 NULL，且约定上 0 表示成功，非零值（如 -1、500）表示不同错误类型。
CREATE PROCEDURE usp_ProcessOrder
@OrderId INT
AS
BEGIN
IF NOT EXISTS (SELECT 1 FROM Orders WHERE Id = @OrderId)
RETURN -1; -- 订单不存在
<pre class='brush:php;toolbar:false;'>IF (SELECT Status FROM Orders WHERE Id = @OrderId) = 'Cancelled'
RETURN -2; -- 订单已取消
UPDATE Orders SET Status = 'Processed' WHERE Id = @OrderId;
RETURN 0; -- 成功END
MySQL 存储过程没有原生 RETURN 状态码机制
MySQL 的存储过程不支持类似 SQL Server 的 RETURN 语句返回执行状态；它只有函数才能用 RETURN 返回标量值。想传递状态，必须借助其他方式：
- 用
OUT参数传回整数状态（最常用，兼容性好） - 用
SELECT输出单行单列结果（但会干扰业务结果集，慎用） - 抛出异常并捕获
SQLSTATE（适合错误场景，但无法自定义语义码）
推荐使用 OUT 参数，调用时显式接收，语义清晰：
DELIMITER $$
CREATE PROCEDURE proc_update_user(
IN p_id INT,
IN p_name VARCHAR(50),
OUT p_status INT
)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
SET p_status = -999;
END;
<pre class='brush:php;toolbar:false;'>IF p_id IS NULL THEN
SET p_status = -1;
LEAVE proc_main;
END IF;
UPDATE users SET name = p_name WHERE id = p_id;
SET p_status = IF(ROW_COUNT() > 0, 0, -2); -- 0=更新成功，-2=未找到记录END$$ DELIMITER ;
PostgreSQL 中用 RAISE NOTICE 或自定义函数返回状态不现实
PostgreSQL 存储过程（PROCEDURE，v11+）本身不支持返回值；函数（FUNCTION）才支持 RETURNS INTEGER。所以真要返回状态码，得改写为函数，并明确声明返回类型：
CREATE OR REPLACE FUNCTION fn_delete_log(p_id INT)
RETURNS INTEGER AS $$
BEGIN
DELETE FROM logs WHERE id = p_id;
IF NOT FOUND THEN
RETURN -1; -- 未找到
END IF;
RETURN 0; -- 成功
END;
$$ LANGUAGE plpgsql;调用时必须用 SELECT fn_delete_log(123)，不能用 CALL —— 这是关键区别。若坚持用 CALL（即真正用 PROCEDURE），就只能靠 OUT 参数或临时表/日志表间接传递状态。
跨数据库统一处理状态码时，别依赖 RETURN 的语义一致性
不同数据库对“返回状态”的实现差异很大：RETURN 在 SQL Server 是语言级特性，在 MySQL 是函数专属，在 PostgreSQL 是函数返回值。强行抽象一层容易踩坑：
- Java/JDBC 中，SQL Server 可用
CallableStatement.getUpdateCount()配合registerOutParameter(1, Types.INTEGER)；MySQL 必须显式注册OUT参数；PostgreSQL 函数则需用SELECT查询结果 - 状态码含义必须在应用层统一定义文档，比如
-1 = record_not_found，不能让各数据库各自解释 - 不要在存储过程中用
PRINT（SQL Server）或RAISE NOTICE（PG）代替状态码——它们无法被程序可靠捕获
真正稳定的做法是：按目标数据库选最自然的机制，再在 DAO 层做薄封装，而不是追求“一套 SQL 走天下”。状态码不是炫技点，是排障依据——可读、可测、可追溯，比形式统一重要得多。
