SQL Server存储过程与自定义函数：语法、选型与性能调优实践

说实话，凡是做 SQL Server 开发的人，早晚都得跟存储过程和自定义函数正面相遇。前面十几篇把建表、查询、索引、事务这些基础过完之后，真正进入业务开发阶段，你会发现一个特别现实的问题：一段需要反复执行的逻辑，比如订单编号生成、跨表状态校验、统计汇总，总不能每次都在客户端现拼 SQL 再发给数据库。写得多了，字符串拼接越来越乱，改动一个规则还要去所有调用方那里同步。存储过程就是用来把复杂的 SQL 逻辑封装到数据库端的方案，而自定义函数则在数据计算和查询复用上有着不可替代的作用。

这篇是 SQL Server 2019 入门系列的第十五篇，我把自己在实际项目中常用的存储过程和自定义函数的语法点、使用方式、选型边界，以及踩过的坑都整理一遍。虽然标题叫入门到精通，但我会尽量从语法骨架讲到参数嗅探、执行计划这一类偏实战的东西，争取让刚入门的人读得懂，也让写过一段时间的人能从中找到一些排查思路。

1. 存储过程与自定义函数：先搞懂服务端对象到底解决了什么问题

1.1 为什么要把逻辑放进数据库端

很多刚接触 SQL Server 的朋友都有一个习惯：所有数据操作都写在 C#、Java 或前端代码里，用 ORM 或者拼接 SQL 的方式去执行。这种做法的优点是改动方便，逻辑全在应用层，但缺点是当业务规则变得复杂起来，SQL 语句会越来越长，而且同样的查询逻辑可能在多个地方重复出现，一旦底层表结构调整，应用代码里所有相关语句可能都要跟着改。

存储过程和自定义函数从本质上说，都是把逻辑放到数据库端，让 SQL Server 作为执行核心。这么设计的好处有三层：

• 第一是复用性。一段封装好的逻辑只需要创建一次，任何客户端都可以通过简单的 EXEC 或 SELECT 去调用，不需要关心内部实现细节。
• 第二是安全性。应用程序不需要直接读取底层表，只要授予存储过程的执行权限，就能避免普通账号拥有直接增删改数据表的权限。很多生产环境的账号权限设计都是基于这个思路。
• 第三是减少网络交互和语法解析开销。复杂逻辑如果放在客户端，可能要发起多次查询然后再做代码级处理；封装成存储过程后，一次调用就能在数据库内完成全部运算，同时执行计划也能被重复利用。

我并不认为存储过程是银弹。现在很多互联网项目出于扩展性和多数据库兼容的考虑，更倾向于把业务逻辑放在应用层，这也有道理。但在传统企业系统、ERP、财务系统这些场景里，存储过程依然是绝对主流。只要数据库是 SQL Server，并且跑的是复杂事务型业务，掌握存储过程和函数就是绕不开的基本功。

1.2 存储过程和函数在功能定位上的关键分歧

存储过程和自定义函数都属于数据库编程对象，但它们在定位上有非常明显的分工。简单来讲，存储过程以“执行一段任务”为核心，它可以包含增删改查、事务控制、循环判断、错误捕获，甚至可以调用其他存储过程；而自定义函数的核心是“返回一个值或一张表”，它主要服务于查询计算和数据转换。

也正是因为这种分工，二者在使用方式上有很大区别。函数可以直接嵌在 SELECT 语句中，比如 SELECT dbo.GetUserName(UserID)，但存储过程不行，你不能在 SELECT 列表里调用一个存储过程。存储过程可以修改表数据，但普通函数内部在绝大多数情况下不允许对表做写操作（除了局部临时表变量）。存储过程可以有输出参数和返回值，而函数的返回值除了标量值就是表结构。这些限制不是 SQL Server 故意为难人，而是它们各自边界的设计使然。

理解了边界，再往下学语法就不会混乱。你现在只需要记住：带有明确操作流程、可能写数据、需要多步骤支持的事务，优先考虑存储过程；纯计算、纯查询、需要在 SELECT 里复用的，优先考虑自定义函数。

2. 存储过程的语法框架与基础使用

2.1 CREATE PROCEDURE 的基本骨架

SQL Server 2019 中创建存储过程的语法主体非常固定：

sql复制CREATE PROCEDURE [schema_name.]procedure_name
    @parameter1 data_type [= default] [OUTPUT],
    @parameter2 data_type [= default],
    ...
AS
BEGIN
    SET NOCOUNT ON;
    -- 业务逻辑
END;

这里有一个很常见的习惯问题：很多人写存储过程时，开头不加 SET NOCOUNT ON。这条语句的作用是不再返回“受影响的行数”这种中间消息，可以显著减少不必要的网络传输，也能避免某些 ORM 框架把 DML 行数误当作结果集。做企业级开发时，我建议所有存储过程开头都写这一句。

AS 和 BEGIN...END 的关系也要注意。单条 SQL 语句在理论上可以省略 BEGIN...END，但只要你写的是存储过程，我建议任何时候都加上，避免后续增加逻辑时不小心把多条语句的范围搞错。

创建一个简单的查询存储过程可以这样写：

sql复制CREATE PROCEDURE dbo.usp_GetUserOrders
    @UserID INT,
    @Status TINYINT = NULL
AS
BEGIN
    SET NOCOUNT ON;
    SELECT OrderID, OrderNo, TotalAmount, OrderDate
    FROM dbo.Orders
    WHERE UserID = @UserID
      AND (@Status IS NULL OR Status = @Status)
    ORDER BY OrderDate DESC;
END;

当 @Status 为空时，这个存储过程返回该用户的所有订单，否则只返回指定状态的订单。这里的 (@Status IS NULL OR Status = @Status) 是一个相当实用的技巧，可以避免为多种参数组合写一堆分支。不过要注意，这样写在某些数据量特别大的查询场景下，可能会导致索引失效，后面讲参数嗅探的时候再展开说明。

2.2 三种数据传递方式：参数、输出参数和返回值

存储过程的数据传递比普通 SQL 语句复杂，它一共有三个维度：

• 输入参数：最常用的方式，在 CREATE PROCEDURE 声明时默认就是输入参数，调用方向过程内传值。
• 输出参数（OUTPUT）：用于把过程内部计算的结果带回给调用方。
• 返回值（RETURN）：RETURN 后面跟一个整数，通常表示执行状态码。

输出参数的一个典型场景是生成单号或获取新插入记录的自增 ID。假设订单表的主键是自增列 OrderID，插入新订单后需要拿到这个值去做后续业务，我们可以这样写：

sql复制CREATE PROCEDURE dbo.usp_InsertOrder
    @UserID INT,
    @TotalAmount DECIMAL(18,2),
    @OrderID INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO dbo.Orders(UserID, TotalAmount)
    VALUES(@UserID, @TotalAmount);
    
    SET @OrderID = SCOPE_IDENTITY();
END;

外部调用它时，必须先声明一个变量接收输出结果：

sql复制DECLARE @NewOrderID INT;

EXEC dbo.usp_InsertOrder
    @UserID = 1001,
    @TotalAmount = 299.00,
    @OrderID = @NewOrderID OUTPUT;

SELECT @NewOrderID AS NewOrderID;

SCOPE_IDENTITY() 这个函数要重点记住，它返回当前会话、当前作用域内最后一次 INSERT 生成的自增值。不要用 @@IDENTITY，因为它在有触发器的情况下会返回触发器里 INSERT 生成的 ID，容易导致数据错乱。输出参数和返回值不是一回事，返回值只有一个，而且通常是整数，适合表示错误码，不适合传递业务数据。很多初学者容易把这两者搞混。

2.3 EXEC 的调用习惯与命名规范

执行存储过程有两种常见方式：EXEC procedure_name 或者省略 EXEC 关键字直接写过程名。但我强烈建议所有地方都显式写 EXEC，特别是在批处理脚本里，否则 SQL Server 解析时容易把过程名误认为某个表，报出一堆莫名其妙的语法错误。

传参也有两种写法：按位置传参和按参数名传参。按位置传参需要注意参数顺序，可读性差；按参数名传参是更稳妥的做法，例如：

sql复制EXEC dbo.usp_GetUserOrders
    @UserID = 1001,
    @Status = 1;

这样一来即使后续给过程增加了可空参数，原来的调用也不容易出错。比较建议在项目中约定一个统一的命名规范，常见做法是业务查询类过程用 usp_Get 前缀，写入操作用 usp_Insert、usp_Update、usp_Delete 前缀，或者用模块名作为前缀，比如 dbo.usp_Order_GetList。清晰的前缀能让你在看到对象名的第一时间就知道它的用途，尤其在数据库对象特别多的老项目里，这个习惯能省下大把排查时间。

3. 存储过程的进阶通病：流程控制、动态 SQL 和异常捕获

3.1 用 IF、WHILE、CASE 解决问题时的实战经验

存储过程真正发挥威力的地方，是它可以用流程控制语句把复杂的判断逻辑组织起来。SQL Server 里最常用的流程控制关键字是 IF...ELSE、WHILE、CASE。CASE 既可以用在 SELECT 返回列里头，也可以用在 SET 赋值语句中。

写 IF 条件时要特别注意一个容易踩的坑：判断一个查询是否有结果，不要用 IF (SELECT COUNT(*) FROM ...)>0，因为 COUNT 会扫描整个表或索引，大表上性能很差。更合理的做法是用 IF EXISTS (SELECT 1 FROM ...)，只要查到一条记录就满足条件，SQL Server 会做短路处理，性能好得多。

WHILE 循环一般用于游标访问或分批更新的场景。很多人在存储过程里一遇到需要逐行处理的情况就直接上游标，然后性能惨不忍睹。这里我总结出来的经验是：能一次性集合操作解决的，坚决不用循环；必须逐条处理时，尽量先取出主键集合，然后用 WHILE 循环 + 主键变量，配合分批提交事务来避免锁竞争和日志膨胀。比如大量数据更新时按 1000 条一个批次循环提交，不仅能降低阻塞风险，还能让出错后的回滚范围可控。

3.2 动态 SQL：能用但别乱用，防注入要当成铁律

动态 SQL 是指通过字符串拼接后再用 EXEC 或 sp_executesql 执行的方式。这在处理“搜索条件不确定、排序字段不确定”的业务场景时很有用，但同时也是 SQL 注入的重灾区。不要在动态 SQL 里直接拼接用户输入的字符串，这是一个雷区，绝对不能碰。

推荐的做法是使用 sp_executesql 配合参数化查询。举个例子，假设我们要根据可选的用户名和订单状态来查询用户，最安全的写法是构造一个带参数的动态 SQL：

sql复制DECLARE @sql NVARCHAR(MAX);
DECLARE @UserKeyword NVARCHAR(50) = '张';
DECLARE @Status INT = 1;

SET @sql = N'SELECT UserID, UserName FROM Users WHERE 1=1';
SET @sql = @sql + N' AND UserName LIKE @kw';
SET @sql = @sql + N' AND Status = @status';

EXEC sp_executesql @sql,
    N'@kw NVARCHAR(50), @status INT',
    @kw = N'%' + @UserKeyword + N'%',
    @status = @Status;

1=1 这个写法在动态拼接条件时很常见，它的作用只是让所有后续 AND 条件都能平滑衔接。动态 SQL 最大的代价是参数变化时执行计划缓存命中率可能下降，并且会绕过存储过程本身的计划复用机制，需要权衡利弊。

3.3 TRY...CATCH 里处理事务的心得

SQL Server 从 2005 开始引入了 BEGIN TRY...BEGIN CATCH 异常处理机制。在存储过程里使用事务时，最标准的写法是把事务放在 TRY 块中，CATCH 块里做回滚和错误抛出。

建议用类似下面的结构：

sql复制CREATE PROCEDURE dbo.usp_TransferAmount
    @FromUserID INT,
    @ToUserID INT,
    @Amount DECIMAL(18,2)
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION;
        
        UPDATE dbo.AccountBalance
        SET Balance = Balance - @Amount
        WHERE UserID = @FromUserID;
        
        IF @@ROWCOUNT = 0
        BEGIN
            THROW 50001, N'转出账户不存在', 1;
        END;

        UPDATE dbo.AccountBalance
        SET Balance = Balance + @Amount
        WHERE UserID = @ToUserID;
        
        IF @@ROWCOUNT = 0
        BEGIN
            THROW 50002, N'转入账户不存在', 1;
        END;

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        
        THROW;
    END CATCH;
END;

这里最关键的是 IF @@TRANCOUNT > 0。为什么 2005 到 2016 之前的很多老教程都会单独判断是否有未提交事务？因为 INSERT、UPDATE、DELETE 出错后，事务是否自动回滚取决于 XACT_ABORT 的设置。如果不开启 XACT_ABORT，部分错误只会回滚当前语句，不会回滚整个事务，导致事务处于“可以提交也可能继续”的奇怪状态。SQL Server 2019 里仍然存在这种情况，所以这套判断完全有必要保留。

THROW 是 SQL Server 2012 开始提供的更简洁的抛错语法，比起旧的 RAISERROR，它不需要写复杂的 format 参数。我在新项目里统一用 THROW，旧代码维护时如果看到 RAISERROR 也能理解，但不建议在新建存储过程里继续写。

4. 自定义函数的分类、编写与边界限制

4.1 先从使用场景最快的标量函数开始

自定义函数分为三种类型：标量值函数（Scalar Function）、内联表值函数（Inline Table-Valued Function）、多语句表值函数（Multi-Statement Table-Valued Function）。

标量值函数返回单一值，比如字符串、日期、数字，通常适合做一些常用计算，或者在查询中把一段重复出现的逻辑抽出来。我经常看到的一种做法是写一个函数来计算订单结算金额，因为多个报表和查询都要用同一套折扣规则。示例：

sql复制CREATE FUNCTION dbo.fn_CalcSettlementAmount
(
    @OrigAmount DECIMAL(18,2),
    @DiscountRate DECIMAL(5,4),
    @CouponAmount DECIMAL(18,2)
)
RETURNS DECIMAL(18,2)
AS
BEGIN
    DECLARE @Result DECIMAL(18,2);
    SET @Result = @OrigAmount * @DiscountRate - @CouponAmount;
    IF @Result < 0
        SET @Result = 0;
    RETURN @Result;
END;

调用方式非常灵活：

sql复制SELECT dbo.fn_CalcSettlementAmount(100.00, 0.85, 10.00);

在 WHERE 子句里直接写函数，如 WHERE dbo.fn_CalcSettlementAmount(...) > 0，是性能杀手，因为 SQL Server 无法有效利用索引。建议把函数计算放到 SELECT 列或 JOIN 条件中，而不是在高频筛选列里滥用。

4.2 内联表值函数：更接近“参数化视图”的存在

内联表值函数（Inline TVF）是我个人在日常工作中使用频率最高的一类自定义函数。它的返回值是一种 TABLE 类型，而且函数体只有一个 RETURN (SELECT ...) 语句，内部没有 BEGIN...END 包起来的多段逻辑。它本质上就是一个参数化视图。

举个例子，一个查询指定用户全部有效订单的通用逻辑，可以这样写：

sql复制CREATE FUNCTION dbo.fn_GetValidOrders
(
    @UserID INT
)
RETURNS TABLE
AS
RETURN
(
    SELECT OrderID, OrderNo, UserID, TotalAmount, OrderDate
    FROM dbo.Orders
    WHERE UserID = @UserID
      AND Status = 1
);

使用时可以把它当作一张表来 JOIN：

sql复制SELECT o.OrderNo, u.UserName
FROM dbo.Users AS u
INNER JOIN dbo.fn_GetValidOrders(u.UserID) AS o
    ON u.UserID = o.UserID
WHERE u.UserStatus = 1;

这个写法最妙的地方在于它支持把外层表的列作为参数传递，也就是俗称的“APPLY 能力”。SQL Server 优化器对于内联表值函数的处理，几乎等同于把函数体内的查询逻辑做一次宏展开，所以性能通常很理想。

4.3 多语句表值函数：使用简单但性能风险高

多语句表值函数（Multi-Statement TVF）的函数体内声明一个表变量，然后通过多条逻辑往里插入数据，最后 RETURN 这个表变量。从功能上看它比内联表值函数灵活，可以做变量声明、逻辑判断、循环和多个查询结果的组合。但从性能角度讲，它可能成为瓶颈，因为在函数内部声明表变量时无法建立统计信息，优化器对它的行数预估往往不准，容易导致外层 JOIN 时计划劣化。

下面是多语句表值函数的典型写法：

sql复制CREATE FUNCTION dbo.fn_GetUserOrderSummary
(
    @StartDate DATE,
    @EndDate DATE
)
RETURNS @Summary TABLE
(
    UserID INT,
    OrderCount INT,
    TotalAmount DECIMAL(18,2)
)
AS
BEGIN
    INSERT INTO @Summary(UserID, OrderCount, TotalAmount)
    SELECT UserID, COUNT(*), SUM(TotalAmount)
    FROM dbo.Orders
    WHERE OrderDate BETWEEN @StartDate AND @EndDate
    GROUP BY UserID;
    
    RETURN;
END;

注意这里 RETURN 后面不需要再跟表变量，只要函数执行到 RETURN 即完成返回。若查询返回的数据量比较大，强烈建议先用临时表替代表变量，或者考虑改成存储过程的输出结果集。在 SQL Server 2019 中，还支持把多语句表值函数内联化，但需要满足很多条件，实际项目里为了稳定，我通常并不刻意依赖这个功能。

4.4 函数里不能做什么：总结几条硬性限制

• 函数内不允许对永久表进行 INSERT、UPDATE、DELETE 操作。只能修改表变量和临时表。
• 函数内不能执行动态 SQL。
• 函数内不能调用存储过程。
• 函数返回的列长度必须明确，不能是 VARCHAR(MAX) 在某些排序、索引场景避免使用。
• 标量函数如果使用 RAND()、NEWID() 这类非确定性函数，会限制其使用范围。

设计的时候需要把这些边界刻在脑子里。特别是“函数内不能执行动态 SQL”这一点，初学者有时候为了绕过限制，会在函数里写 EXEC (@sql)，然后系统直接报错。原因不是 SQL Server 没做到，而是函数本身需要保证确定性和可预测性，如果允许它执行任意动态文本，统计优化器和并行执行都无从谈起。

5. 存储过程与自定义函数的选择：不是谁替代谁，而是各管一段

5.1 一张表把边界和区别看明白

这张表基本能当成选型速查。撰写存储过程时若遇到“是不是该改成函数”的犹豫，先拿这张表对照一遍，大多数疑问都会迎刃而解。

5.2 实际选型时我的决策思路

假如业务需求是“把一个订单金额从一种币种折算为另一种币种”，并且这段计算要在 10 个报表里复用，那标量值函数明显更合适。假如需求是“根据筛选条件导出结算报表”，需要先建临时表做中间计算，再输出最终结果集，那存储过程更适合，因为它可以灵活地使用临时表和事务。

还有一种情况是既有计算又有数据变更，比如“导入订单文件并自动计算税额”。如果把这整个流程封装成函数，会直接撞上函数不能写永久表的限制；因此正确方案是写一个存储过程，过程内先做导入的校验和 INSERT，然后调用标量函数计算税额，再把结果更新到数据行中。存储过程和函数并非二选一，它们可以在一个流程里互相配合，函数负责纯计算，存储过程负责整个流程编排。

如果项目组里有同事特别喜欢把所有逻辑都写成标量函数然后在 SELECT 列表里大量调用，一定要提醒他注意性能。标量函数在 SQL Server 2019 里虽然支持了内联化改进，但并非所有函数都能自动内联，调用成千上万行时每一行都做函数调用，开销会被指数放大。之前我在一个查询里直接引用了三层嵌套的自定义标量函数，处理几十万行时耗时从几百毫秒直接飙到分钟级。解决办法是把函数计算改写为 JOIN 子查询或 CASE 表达式，性能完全不是一个量级。

6. 参数嗅探、执行计划与日常调优

6.1 为什么同样一个存储过程，有时候快有时候慢

存储过程在执行时会经历“解析-编译-执行”三个阶段。为了提高效率，SQL Server 会把第一次执行生成的执行计划放入计划缓存，后续调用如果参数相同或计划可复用，就直接使用缓存计划。

但在实际业务中，如果同一个存储过程初次执行时传入的参数刚好偏向某个极端，SQL Server 生成的计划就会偏向这个参数的数据分布。之后哪怕传入的数据分布完全不同，它也会沿用旧计划，这就叫参数嗅探（Parameter Sniffing）。

比较常见的场景是存储过程里有一个可选筛选条件：某次调用传入了一个在表中占比极低的值，优化器决定走索引 Seek，计划效果很好；另一次调用该参数默认不传或传入高占比的值，本该走全表扫描更快，但它还是用了 Seek，导致大量键值查找，查询变得非常慢。解决参数嗅探的办法很多，比如使用 OPTION(RECOMPILE) 在每次执行时都重新编译，或者把参数赋值给局部变量再使用。

在 SQL Server 2019 中，还有一个进阶选项是 OPTION(USE HINT(N'DISABLE_PARAMETER_SNIFFING'))，它可以对整个数据库或查询级别关闭参数嗅探。但这些处理都要谨慎，因为一概重编译虽然避免了旧计划问题，但也会牺牲计划缓存带来的好处。在核心业务存储过程中，我通常用局部变量方案解决，宁可多做几次编译，也不愿用户明显感受到卡顿。

6.2 如何快速定位慢存储过程和查看执行计划

当某个存储过程响应速度明显变慢时，第一步是找到它的执行统计。最直接的办法是 sys.dm_exec_query_stats 和 sys.dm_exec_procedure_stats 联查，按总耗时排序找出可疑的过程：

sql复制SELECT TOP 10
    OBJECT_NAME(ps.object_id, ps.database_id) AS ProcName,
    ps.execution_count,
    ps.total_worker_time / 1000000.0 AS TotalCPUSec,
    ps.total_elapsed_time / 1000000.0 AS TotalElapsedSec,
    ps.last_elapsed_time / 1000000.0 AS LastElapsedSec
FROM sys.dm_exec_procedure_stats AS ps
WHERE ps.database_id = DB_ID()
ORDER BY ps.total_elapsed_time DESC;

定位到特定存储过程之后，可以临时用 SET STATISTICS IO ON; SET STATISTICS TIME ON; 来看每个语句的逻辑读次数和 CPU 耗时。想真正看清楚执行计划，最简单的方法是 SQL Server Management Studio（SSMS）中选中存储过程，点击“包含实际执行计划”后执行，然后在“执行计划”标签页观察有没有表扫描、键值查找、隐式转换警告等图标。

逻辑读次数是最直观的调优指标。一次逻辑读对应读取一个 8KB 页面，如果一条查询逻辑读是几万次，即使响应时间不到一秒，数据量稍微增长也容易出问题。所以我在排查存储过程时很少先看“运行了多少秒”，而是先看每个操作符的逻辑读。许多情况下，把一次几十万逻辑读的查询优化成几千，执行时间自然就下来了。

6.3 我在真实项目里遇到的典型性能问题与修正记录

之前有一个复杂的生产报表存储过程，每天都跑，但某一天突然慢了一倍多。查看执行计划后发现某个大表统计信息过期，优化器预估的数据行数与实际差异巨大，导致它生成了一个嵌套循环连接，而实际数据量让这个连接操作执行了数千万次。解决办法很简单：更新该表统计信息后重新编译存储过程，问题立刻消失。后续我把它当作一个重要经验，就是存储过程变慢不一定是代码错误，统计信息过期是很常见的隐藏因素。

另外一个典型问题是条件里字段类型不一致导致隐式转换。例如某个查询表里字段是 NVARCHAR，但代码中传入的是字符串字面量，SQL Server 执行时会把列转换为 NVARCHAR 进行比较，索引失去作用，系统产生大量扫描。排查时如果看到执行计划里 SELECT 运算符出现感叹号，检查是否有 CONVERT_IMPLICIT 警告。修复方案是统一参数类型或统一列类型，这是入门级但很容易被忽略的坑。

7. 常见问题与排查技巧实录

7.1 创建对象时报 “必须声明标量变量” 或 “无效的列名”

常见于初学者在 CREATE PROCEDURE 中写了 SELECT 列，但列名写错，或参数名和表列名混淆。写过程时建议给所有列名添加表别名前缀，比如 o.OrderID，如果出现一个列在多个表中都存在，不写别名会导致 “Ambiguous column name” 错误。而在 PROC 中使用与列名相同的参数名时也要注意，SQL Server 解析参数和列名有一定优先规则，容易造成“该列名不明确”的报错。统一的前缀习惯是最有效的规避手段。

7.2 函数或存储过程一直报 “SQL Server blocked access to ... ”

这类错误通常跟权限配置有关系。存储过程要执行权限，用户至少需要数据库的 EXECUTE 权限，如果过程中访问了其他库的对象，还涉及跨库权限。生产环境中不要直接给 sa 或 sysadmin，应使用最小权限原则，只授予所需对象的 EXECUTE 权限或 SELECT 权限。还有一个常见问题是函数本身使用了非确定性内置函数，然后把它用在计算列或索引视图上，SQL Server 会拒绝创建，这种时候需要检查是否真的需要索引视图，或者改为持久化计算列。

7.3 出现 “Invalid object name” 但表明明存在

这个通常不是表真不存在，而是当前数据库上下文不对。例如在 msdb 数据库中调用 dbo.usp_GetOrders，而该存储过程建在业务库中。此问题常见于跨库检索中用错了库名。解决方式是调用时使用完整的对象名，如 SalesDB.dbo.usp_GetOrders；在存储过程内部如果要跨库访问，也需要在对象名前加库名前缀。

7.4 查看存储过程执行计划时无法定位问题

很多初级 DBA 会看图形执行计划，却不认识那些图标。如果把鼠标悬停在某个图标上，发现“Estimated Number of Rows”和“Actual Number of Rows”差距极大，说明优化器预估严重失准，优先检查统计信息和索引。另一个高频错误是在 WHERE 条件里使用了函数或表达式，比如 WHERE YEAR(OrderDate) = 2024，这会导致 OrderDate 列上的索引失效，因为无法对表达式做索引查找。正确写法应该是 WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'。

7.5 怎样正确查看某存储过程的执行历史

热搜词里出现“dm 管理工具怎么查看某个存储过程的执行计划”。我推测这里的 “dm” 其实是某些国产数据库的管理工具，但思路完全可以迁移到 SQL Server 中：一是在 SSMS 中通过 sys.dm_exec_procedure_stats 查看累计执行耗时，二是通过扩展事件或 SQL Profiler 抓取该过程的最新执行语句，三是在实际执行时打开“包含实际执行计划”功能。查看执行计划的核心不是有没有按钮，而是看懂执行计划中开销占比最大的操作符，并针对它做索引和语句调整。

8. 最后再分享一个小技巧：用系统视图快速摸清库里到底有哪些过程与函数

我经常接手一些旧项目，一打开对象资源管理器，看到上百个存储过程和函数，没有注释也没有版本管理。这时候我会跑一组系统查询，几分钟内摸清全貌：

sql复制-- 查看所有存储过程和函数的基本信息
SELECT
    o.name AS ObjectName,
    o.type_desc AS ObjectType,
    m.definition AS ObjectDefinition
FROM sys.sql_modules AS m
INNER JOIN sys.objects AS o
    ON m.object_id = o.object_id
WHERE o.type IN ('P', 'PC', 'FN', 'IF', 'TF')
ORDER BY o.type_desc, o.name;

这个查询会把每个对象的创建语句全部带出来，配合 OBJECT_ID 可以快速定位具体逻辑。若想查看某个函数或过程被哪些对象引用，可以用 sys.sql_expression_dependencies 分析依赖关系。在不了解一个庞大系统的业务现状时，这组视图比任何文档都准确，因为文档可能过期，但代码不会骗人。

SQL Server 2019 中的存储过程和自定义函数虽然基础，却是无数业务系统数据流转的基石。应用开发人员可以不懂高深的性能调优，但一旦能熟练处理好参数传递、错误处理、函数边界和执行计划，写出来的代码质量和维护成本都会有非常明显的改变。