SQL Server 用 EXEC @var = proc 捕获 INT 型 RETURN 值，必须显式 RETURN 且变量需声明为 INT；MySQL 不支持 RETURN，须用 OUT 参数传递值，返回值仅适合状态码，多行数据需用临时表或结果集。
SQL Server 中只能用 EXEC @var = proc_name 捕获整数返回值，且必须是显式 RETURN 的 INT；MySQL 根本不支持这种返回值，得靠 OUT 参数；别指望用 SELECT 或函数式写法去接它——全会报错。
SQL Server：EXEC @ret = proc 的硬约束
这个语法看着像赋值，其实是 SQL Server 特有的“执行并捕获状态码”机制，不是通用返回值接收方式。
-
RETURN值只能是INT，不能为NULL，没写RETURN就默认返回0——这常被误判为“成功”，实际可能是逻辑未覆盖分支 - 必须声明变量，且类型严格为
INT：DECLARE @result INT; EXEC @result = usp_CheckUser @id = 123; - 不能写成
SELECT * FROM (EXEC usp_CheckUser 123)或@result = EXEC usp_CheckUser 123，语法直接报错 - 被调过程里必须有明确
RETURN 1、RETURN -1这类语句，光靠SELECT或SET不会产生返回值
MySQL：根本没 RETURN 这回事，全靠 OUT 参数
MySQL 存储过程不支持 RETURN 语句返回标量值，所有“返回”都得走参数通道。
- 被调过程定义必须含
OUT或INOUT参数：CREATE PROCEDURE check_user(IN uid INT, OUT status TINYINT) - 调用时传入变量名即可，不用再写
OUT关键字：CALL check_user(123, @status); - 字符串类输出要注意长度限制：
OUT msg VARCHAR(200)，超长会被截断，且不会报错 - 如果主过程里声明了
@status却没在CALL中传入，该变量保持NULL，不会自动初始化
想拿结果集？别碰返回值，用临时表或表变量
返回值只适合状态码（0/-1/1），要取多行或多列数据，必须绕过 RETURN 和 OUT，走结果集路径。
- SQL Server：用
#tmp临时表，结构必须和被调过程的SELECT输出完全一致（列数、顺序、类型）：CREATE TABLE #users(id INT, name NVARCHAR(50)); INSERT INTO #users EXEC usp_GetUsers @dept = 5; - SQL Server 表变量（
DECLARE @t TABLE(...)）不能用于INSERT INTO @t EXEC ...，会报错，仅限INSERT INTO @t SELECT ... - MySQL：没有
INSERT ... EXEC等价语法，得用临时表 +CREATE TEMPORARY TABLE+INSERT INTO ... SELECT模拟，或改用函数封装查询逻辑 - 跨库调用时，SQL Server 必须用三段式名：
EXEC [OtherDB].[dbo].[usp_GetData]，否则可能调错同名过程
权限与事务：容易静默失败的两个盲区
调用能跑通不代表逻辑正确，权限和事务边界经常被忽略。
- 被调过程若在另一数据库，调用方用户需有目标库的
EXECUTE权限：GRANT EXECUTE ON [OtherDB].[dbo].[usp_Check] TO [app_user]，否则报“拒绝访问”而非语法错误 - SQL Server 中嵌套调用默认继承外层事务，但被调过程若含
COMMIT或ROLLBACK，可能提前结束整个事务链——尤其在异常处理块里漏写SAVE TRANSACTION时 - MySQL 存储过程默认不参与调用方事务（除非显式开启），
CALL内部的COMMIT会立即生效，无法回滚外层操作 - 嵌套深度上限为 32 层，递归调用或深层链式调用容易触发
Maximum stored procedure nesting level exceeded
真正麻烦的从来不是语法怎么写，而是你默认返回值能传字符串、能为 NULL、能当结果集用——它不能。每种机制的边界比文档写的更窄，错配类型、漏写 OUTPUT、混用 MySQL 和 SQL Server 习惯，都会让过程静默失败或返回意外值。
