SQL Server存储过程中应设SET NOCOUNT ON并仅保留一个末尾SELECT；函数禁用INSERT/UPDATE因需无副作用；空参查询须用IF分支或显式NULL处理；标量函数应避免嵌套，优先用ITVF或内联优化。
存储过程里怎么安全返回结果集又不被客户端当多结果集报错
SQL Server 存储过程中用 SELECT 返回数据，如果调用方（比如 C# 的 SqlCommand.ExecuteReader()）没处理好，容易抛出“无法在具有多个活动结果集的连接上执行命令”这类错误。根本原因不是语句写错了，而是你没显式控制结果集生命周期。
实操建议：
- 在存储过程开头加
SET NOCOUNT ON，避免每条INSERT/UPDATE/DELETE都触发一行“X 行受影响”的隐式结果集 - 只保留一个
SELECT作为最终输出，且放在最后；中间临时计算用表变量或INSERT INTO @table，别用SELECT打断流 - 如果必须分步调试输出，改用
RAISERROR('debug: xxx', 0, 1) WITH NOWAIT，它不产生结果集 - 在 C# 中确保
SqlDataReader调用NextResult()前已读完当前结果集，或直接用DataTable.Load()自动跳过非查询结果
函数里为什么不能用 INSERT/UPDATE/SELECT INTO
SQL Server 标量函数和内联表值函数（ITVF）有严格限制：任何会修改数据库状态或依赖临时对象的操作都会报错，典型错误是 Invalid use of a side-effecting operator 'INSERT' within a function。
这不是权限问题，是 SQL Server 引擎的确定性约束——函数必须可重复执行、无副作用，否则无法用于索引视图、CHECK 约束等场景。
实操建议：
- 需要写入逻辑？必须用存储过程，别硬塞进函数
- 想封装查询逻辑又想复用？优先写成内联表值函数（
RETURNS TABLE AS RETURN (SELECT ...)），它本质是参数化视图，支持 JOIN 和优化器展开 - 若真要“计算+写日志”，可在函数外层用存储过程调用函数获取结果，再单独
INSERT日志表 - 注意：多语句表值函数（MSTVF）虽允许
INSERT INTO @t，但性能极差，执行计划常退化为嵌套循环，慎用
存储过程参数传 NULL 时 WHERE col = @p 总查不到数据
这是空值比较的经典陷阱：NULL = NULL 返回 UNKNOWN，不是 TRUE，所以 WHERE name = @name 在 @name 为 NULL 时永远不匹配任何行。
实操建议：
- 显式处理空参：
WHERE (@name IS NULL OR name = @name)，但注意这会让索引失效（除非用 IF 分支） - 更优解是用 IF 判断参数是否为空，走不同查询分支：
IF @name IS NULL SELECT ... ELSE SELECT ... WHERE name = @name，让优化器为每条路径生成独立执行计划 - 避免用
ISNULL(@name, '') = ISNULL(name, '')，它强制对列做函数运算，必然导致索引扫描 - 如果参数来自前端且可能为空，建议在应用层就过滤掉空值，或统一转成特殊标记值（如
'[ALL]'），再在 WHERE 中用CASE处理
函数嵌套太深导致执行慢得离谱
SQL Server 不会内联多层标量函数（哪怕只有一行 RETURN @x + 1），每次调用都变成一次独立执行上下文切换，10 万行数据调用 10 层函数，实际执行次数可能是百万级。
实操建议：
- 标量函数能不用就不用；把简单计算逻辑直接写进查询，比如
LEN(name) > 5比dbo.fn_is_long_name(name)快十倍以上 - 必须复用逻辑？改用内联表值函数（ITVF），它会被优化器展开为子查询，参与整体计划优化
- 已有大量标量函数调用？可用
sys.dm_exec_function_stats查看total_logical_reads和execution_count，定位高开销函数 - SQL Server 2019+ 支持标量函数内联（需兼容级别 150+ 且函数满足纯计算条件），但默认关闭，需加
WITH INLINE = ON显式启用
最麻烦的不是语法写不对，是函数看着简洁，执行时悄悄拖垮整个查询。上线前跑个 SET STATISTICS IO ON，看看逻辑读是不是翻了几十倍——那八成是函数在背后反复自闭。
