ddl触发器无法捕获存储过程执行计划，因其仅响应结构变更事件；真正可行的是扩展事件（如rpc_completed配合plan_handle查sys.dm_exec_query_plan），sql trace/profiler已弃用。
DDL触发器不能捕获存储过程执行计划
DDL触发器只响应数据库结构变更事件（如 CREATE_PROCEDURE、ALTER_PROCEDURE），它对运行时的 EXEC 或 sp_executesql 调用完全无感知，更不会拿到执行计划。试图用它记录“谁在什么时候调用了哪个存储过程并生成了什么计划”，这条路从机制上就走不通。
真正能抓到执行计划的只有扩展事件（XEvent）
SQL Server 2012+ 推荐且唯一支持实时捕获执行计划的机制是扩展事件，尤其 query_post_execution_showplan 事件（需开启 showplan 权限）或更轻量的 rpc_completed + sql_batch_completed 配合 query_plan_hash 和 plan_handle 关联查 sys.dm_exec_query_plan。
-
query_post_execution_showplan开销大，仅建议短时调试，生产环境慎用 - 若只想确认“某存储过程是否被调用”，用
rpc_completed过滤object_name字段最直接 - 要关联具体执行计划，必须保留
plan_handle并在事件触发后立即查sys.dm_exec_query_plan(plan_handle)，延迟查可能因计划被驱逐而失败 - 记得添加
WHERE object_name = N'YourProcName'筛选，避免日志爆炸
加密存储过程让文本搜索失效，但不影响运行时追踪
即使存储过程用了 WITH ENCRYPTION，它的执行行为（调用时间、参数、CPU/读写、执行计划）仍完整暴露在 XEvent 和 DMV 中。你无法从 sys.sql_modules 或旧式 syscomments 里搜到它的定义，但这对动态追踪毫无影响——因为 SQL Server 执行时解密后的计划树已进入内存，XEvent 捕获的就是这个阶段的数据。
- 别再尝试解密后 grep 文本，那是过时且不可靠的思路
-
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对加密对象返回空或不准确，不可信 - 真正稳定的方式是：建一个轻量 XEvent session，只捕获
rpc_completed，过滤目标过程名，写入环形缓冲区（ring_buffer）——几秒内就能查到刚发生的调用
