SQL Server无函数式存储过程，需用标量函数（单值计算）或表值函数（结果集）替代；标量函数禁用DML和非确定性函数，ITVF性能优于MSTVF；MySQL函数须声明DETERMINISTIC等属性；跨库复用宜用视图+参数化查询。
SQL Server 里没有函数式存储过程，得用标量函数或表值函数替代
SQL Server 的 CREATE PROCEDURE 本身不支持返回值（除 RETURN 整数状态码外），没法像函数那样嵌入查询中复用逻辑。真想封装通用逻辑，优先选 CREATE FUNCTION ——但必须分清场景：SCALAR 函数适合单值计算（比如格式化日期、脱敏手机号），TABLE 函数适合返回结果集（比如按租户过滤的通用权限视图）。
常见错误是强行把带 INSERT/UPDATE/EXEC 的业务逻辑塞进函数——SQL Server 不允许，会直接报错 Invalid use of a side-effecting operator。这类操作只能留在存储过程中，复用靠参数化 + 拆解原子步骤。
- 标量函数不能含 DML、临时表、
GETDATE()等非确定性函数（除非显式声明WITH SCHEMABINDING并避开限制） - 内联表值函数（
ITVF）性能好、可推导执行计划；多语句表值函数（MSTVF）会物化中间结果，大数据量下明显变慢 - 函数里调用
EXEC或动态 SQL 是禁止的，这点比存储过程严格得多
MySQL 8.0+ 可用存储函数（FUNCTION），但注意权限和只读限制
MySQL 允许创建 CREATE FUNCTION，能返回标量值，也支持在 SELECT 中直接调用。但它对定义者权限要求高：必须有 CREATE ROUTINE 权限，且默认开启 log_bin_trust_function_creators=OFF 时，函数还必须声明为 DETERMINISTIC、NO SQL 或 READS SQL DATA，否则建不成功。
典型踩坑是写了个读配置表的函数，没加 READS SQL DATA，执行时报错 This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration。更隐蔽的问题是：函数体内不能修改数据（哪怕只是 INSERT INTO tmp SELECT ...），否则会触发 Not allowed to return a result set from a function。
- 函数名不能和内置函数冲突，比如叫
format_date没问题，叫date就会报错 - 参数类型必须明确指定长度，
VARCHAR(50)不能简写成VARCHAR - 返回值类型要和实际
RETURN的表达式类型严格一致，隐式转换可能失败
跨数据库通用复用？别硬套“函数”概念，用视图 + 参数化查询组合
PostgreSQL、Oracle、SQL Server 都支持视图，但视图不接受参数。想实现类似效果，得靠客户端传参拼接，或服务端用临时表/表变量兜底。例如在 SQL Server 中，可先用 INSERT INTO #filter_config SELECT @tenant_id, @status，再让通用存储过程从 #filter_config 读取条件——这比硬造一个“万能函数”更可控。
另一个思路是把高频逻辑抽象成视图（如 v_active_users），再配合应用层生成 WHERE 条件。虽然不算“封装到数据库内”，但避免了各数据库函数语法差异带来的维护成本。真正容易被忽略的是：视图字段别名一旦定死，下游改名就得全链路更新，不如函数参数名灵活。
- 视图里用
GETDATE()是安全的，但 PostgreSQL 的NOW()在物化视图中可能冻结时间点 - Oracle 的
WITH子句临时结果集不能跨查询复用，得靠GLOBAL TEMPORARY TABLE - 所有方案都绕不开权限问题：函数/视图的执行权限 ≠ 基础表权限，常漏授
SELECT给函数依赖的表
存储过程内部怎么拆解才利于复用？聚焦“无状态原子操作”
把一个 300 行的订单处理存储过程拆成复用单元，关键不是切得越碎越好，而是识别出哪些步骤不依赖上下文、不修改共享状态。比如“校验库存是否充足”可以独立为 usp_check_stock，输入 @product_id 和 @quantity，输出 @is_available BIT；但“扣减库存并记录日志”就必须和事务绑定，不能单独拎出来当通用函数用。
容易被忽略的细节是错误处理粒度：在原子存储过程中用 THROW 抛出自定义错误号（如 50001），上层调用方用 TRY...CATCH 捕获，比全堆在一个大过程里用 @@ERROR 判断清晰得多。另外，所有输入参数建议加默认值（= NULL），避免调用时漏传导致意外行为。
- 原子过程只做一件事：查、算、判，不做事务控制（BEGIN/COMMIT 留给调用方）
- 输出参数命名统一加
@out_前缀（如@out_error_msg），避免和输入参数混淆 - 不要在原子过程中用临时表存中间结果——它无法被调用方访问，得改用表值参数或返回结果集
