SQL Server存储过程调用追踪与执行计划记录方法

监控存储过程执行计划是数据库性能调优中的常见需求，但许多开发者最初会误入歧途，例如尝试使用DDL触发器来实现。这里需要首先明确：这种方法从根本上就是行不通的。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

DDL触发器无法捕获存储过程执行计划

为何此方法无效？因为DDL触发器的设计初衷是响应数据库架构变更事件，例如存储过程的创建（CREATE_PROCEDURE）或修改（ALTER_PROCEDURE）。对于运行时的EXEC命令调用或sp_executesql的动态执行，它完全无法感知，更不用说获取其生成的执行计划了。因此，试图通过DDL触发器来记录“何人、何时、调用了哪个存储过程、产生了何种执行计划”，在机制设计层面就已注定失败。

扩展事件（XEvent）是捕获执行计划的正确工具

那么，正确的技术方案是什么？对于SQL Server 2012及更高版本，官方推荐且唯一支持实时捕获执行计划的机制是扩展事件（Extended Events）。

具体而言，你可以监控query_post_execution_showplan事件，它能直接捕获完整的执行计划XML数据。但需注意，启用此事件需要SHOWPLAN权限，并且由于它会捕获所有查询的计划，对系统性能有一定开销，通常仅建议在短期诊断调试时使用，生产环境务必谨慎评估。

更轻量级且常用的方案是监听rpc_completed（针对远程过程调用）和sql_batch_completed事件。这两个事件本身不直接包含计划详情，但会提供关键的plan_handle（计划句柄）。获取此句柄后，你可以立即关联查询动态管理视图sys.dm_exec_query_plan，从而提取具体的执行计划内容。

• 若仅需确认“某个特定存储过程是否被调用”，最直接的方法是在rpc_completed事件上添加过滤器，依据object_name字段进行精准筛选。
• 若需关联具体的执行计划进行分析，则必须在事件配置中捕获plan_handle字段，并在事件触发后尽快执行sys.dm_exec_query_plan(plan_handle)查询。这里有一个关键要点：查询动作必须迅速。因为执行计划可能从缓存中被清除，延迟查询可能导致无法获取结果。
• 无论采用哪种方式，都强烈建议通过WHERE object_name = N‘YourProcName’此类条件进行筛选，否则日志数据量可能急剧增长，影响系统性能。

加密存储过程不影响运行时追踪

另一个常见疑问是：如果存储过程使用了WITH ENCRYPTION选项进行加密，是否就无法追踪了？答案是：加密不影响运行时行为的监控。

加密保护的是存储过程的定义文本（源代码），你将无法从sys.sql_modules或旧的syscomments系统视图中查看其源码。但这对于动态追踪其执行行为——例如调用时间、传入参数、消耗的CPU/IO资源、生成的执行计划——完全没有影响。因为SQL Server在执行时，会将解密后的计划加载到内存中，而扩展事件捕获的正是这个运行时阶段的数据。

• 因此，无需再尝试解密存储过程并进行文本搜索，这是一条过时且不可靠的路径。
• 实际上，像sys.dm_exec_procedure_stats这样的动态管理视图，可以直接提供每个加密存储过程的累计执行次数、平均耗时、最近执行时间等聚合性能指标。
• 你还可以结合sys.dm_exec_cached_plans和sys.dm_exec_sql_text，定位到缓存中该过程对应的实际plan_handle。

避免使用已弃用的SQL Trace / Profiler

最后，必须明确一条技术红线：所有基于sp_trace_*系列系统存储过程或SQL Server Profiler图形化工具的方案，在SQL Server 2022及后续版本中已被官方标记为“已弃用”。这意味着未来版本可能会彻底移除这些功能。微软官方文档反复强调：新的开发必须使用扩展事件，现有系统也应尽快完成迁移。

• 即使在Profiler界面上仍能看到“重播”或“数据库引擎优化顾问”等功能，其底层依然依赖已被淘汰的Trace文件格式（.trc）。
• 此外，像sp_depends或sys.dm_exec_describe_first_result_set这类依赖对象元数据的工具，对于加密对象可能返回空值或不准确信息，不可完全依赖。
• 真正稳定可靠的做法是：创建一个轻量级的扩展事件会话，仅捕获rpc_completed事件，并通过过滤器指定你的目标存储过程名，将事件数据输出到环形缓冲区（ring_buffer）中。这样，几秒钟内即可查询到刚刚发生的调用记录。

归根结底，执行计划并非静态存储于某张表中的元数据。它仅存在于查询被执行的那个瞬间，存活于内存之中。想要捕获它，就必须在那个短暂的时间窗口内，使用正确的监听机制。请停止从源代码或DDL变更记录中寻找答案的尝试，方向错误，努力将付诸东流。