存储过程用于数据修改、事务处理和多结果返回，函数仅限纯读计算且不可修改数据库状态；涉及dml、流程控制、多输出或非确定性操作时必须用存储过程。

要改数据、做事务、返回多个结果，就用存储过程；只计算、不写库、要嵌进SELECT里，就用函数。

需要执行 INSERT/UPDATE/DELETE 时必须用 CREATE PROCEDURE

函数在 MySQL、SQL Server、PostgreSQL 中都明确禁止修改数据库状态。一旦你在 CREATE FUNCTION 里写 UPDATE users SET status = 'active'，直接报错：Invalid function definition: Cannot modify a table in a function。而存储过程天然支持 DML，还能配合 BEGIN TRANSACTION 和 ROLLBACK 做一致性保障。

常见错误现象：

• 把批量发优惠券逻辑硬塞进函数，结果编译失败
• 想用函数记录操作日志（INSERT INTO audit_log），被数据库拦住

实操建议：

• 涉及多表更新、状态流转、定时任务触发的数据变更，一律走 CREATE PROCEDURE
• 哪怕只是“查+改”两步，只要含写操作，就不能用函数
• 函数里调用另一个含写操作的存储过程？也不行——函数体内禁止 EXEC 或 CALL

要在 SELECT 或 WHERE 中动态生成字段值，优先选函数

比如把 user_id 转成脱敏手机号、根据订单金额算税后价、把时间戳转为“3小时前”这类纯读+计算场景，函数能直接当表达式用：SELECT name, dbo.mask_phone(mobile) FROM users。存储过程做不到这点——它不能出现在 SELECT 列表里，也不能在 WHERE 条件中调用。

性能影响要注意：

• 标量函数在大表上被逐行调用，可能拖慢整个查询（尤其没内联优化的数据库）
• MySQL 的函数不支持 GETDATE() 这类非确定性函数，否则创建失败
• SQL Server 中，函数不能用 TRY...CATCH，出错只能靠上层捕获

实操建议：

• 确认逻辑只读、无副作用，再封装成函数
• 高频调用的计算逻辑，优先用内置函数（如 ROUND()、CONCAT()），比自定义函数更稳
• 需要返回多列或多行？别硬撑——改用表值函数（RETURNS TABLE）或直接用存储过程 + SELECT 输出结果集

需要输出多个值或控制流程分支，只能选存储过程

函数只允许一个 RETURN，且类型固定（标量或表）。但业务中常要同时返回新插入的 ID、处理条数、错误码等——这只能靠存储过程的 OUT 参数实现：CREATE PROCEDURE sp_create_order @cust_id INT, @order_id INT OUTPUT, @affected_rows INT OUTPUT。另外，IF、WHILE、游标、临时表这些流程控制能力，函数基本不支持（表值函数除外）。

容易踩的坑：

• 误以为函数能用 DECLARE @temp TABLE —— 标量函数里连表变量都不让建
• 想在函数里判断条件后返回不同格式字符串，结果发现分支逻辑写不下去
• 把本该用 OUT 参数返回的状态码，硬塞进字符串拼接里传出来，后续解析困难

实操建议：

• 接口需返回成功/失败+详情信息时，用存储过程 + 多个 OUT 参数比拼 JSON 字符串更可靠
• 复杂 ETL 步骤（查源→清洗→校验→落库→发通知）必须用存储过程，函数撑不住
• 注意 SQL Server 中，函数不能调用 GETDATE()，但存储过程可以——时间敏感逻辑别放错地方

最常被忽略的一点：函数在查询计划中可能被多次求值，尤其是没标记为 DETERMINISTIC 时；而存储过程的执行边界清晰，调试和监控都更容易定位。选型不是看“哪个更高级”，而是看“哪条路不会在半道被数据库拦下来”。