SQL Server 2014 Express中相似sp_execute事件的性能问题排查

一、执行时长飙升的可能原因 #

• 参数化查询执行计划劣化：sp_execute用于执行sp_prepare生成的参数化查询（你看到的30是语句句柄，112768是参数值）。即便参数一致，若表的统计信息过期，SQL Server可能会选择低效的执行计划——比如数据分布发生变化后，旧计划无法适配新的数据量或分布状态。
• 单点阻塞/资源等待：服务器整体负载正常不代表无局部阻塞。如果该查询需要的资源（如行锁、页锁）被其他会话占用，后续相同查询会进入等待队列，执行时长被大幅拉长。连续的相同请求更容易触发这类链式阻塞。
• 客户端重复请求（含你推测的场景）：确实存在这种可能。比如客户端应用逻辑错误（如重试机制误触发）、网络丢包导致客户端判定请求未送达，重复发送相同的sp_execute指令。当大量重复请求堆积，会占用SQL Server工作线程，引发队列拥堵，进而拉长单请求的执行时间。
• 内存授予不足：若查询涉及排序、哈希匹配等需要大量内存的操作，即便服务器整体内存负载正常，也可能存在内存分配竞争，导致SQL Server不得不使用tempdb完成操作，这会大幅增加执行耗时。

二、从追踪中提取更多信息的方法 #

1. 获取原始查询文本 #

sp_execute的第一个参数是语句句柄（示例中的30），你需要在追踪中找到对应的sp_prepare事件，它包含实际的SQL语句。操作方式：

• 在追踪工具（SQL Server Profiler或Extended Events）中添加Prepare SQL或SP:StmtCompleted事件，过滤StatementHandle等于目标值的记录，即可拿到原始查询内容。

2. 排查阻塞与等待类型 #

• 在追踪中添加Wait Statistics事件，查看该sp_execute会话的等待类型：LCK_M_*代表锁等待，PAGEIOLATCH_*代表磁盘IO等待，RESOURCE_SEMAPHORE代表内存等待，这些能直接指向性能瓶颈。
• 问题发生时，执行以下查询查看实时请求状态：

  SELECT r.session_id, r.wait_type, r.wait_time, r.blocking_session_id, t.text
  FROM sys.dm_exec_requests r
  CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
  WHERE r.session_id IN (/* 追踪中找到的执行sp_execute的会话ID */)
  

  该语句能直接显示是否被其他会话阻塞，以及阻塞源的SQL内容。

3. 分析执行计划 #

• 通过语句句柄关联获取执行计划：

  SELECT cp.plan_handle, qp.query_plan
  FROM sys.dm_exec_cached_plans cp
  CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp
  WHERE cp.objtype = 'Prepared'
  AND EXISTS (
      SELECT 1 FROM sys.dm_exec_sql_text(cp.plan_handle) st
      WHERE st.statement_handle = 30 -- 替换为你的语句句柄
  )
  

  查看计划中是否存在高成本操作（如全表扫描、大量排序），或不合理的连接方式。

4. 验证统计信息状态 #

• 手动更新查询涉及表的统计信息，观察执行时长是否恢复：

  UPDATE STATISTICS [目标表名] WITH FULLSCAN;
  

  若更新后性能改善，说明统计信息过期是核心问题。

三、验证客户端重复请求的方法 #

• 检查应用服务器日志，确认是否有重复请求记录，或客户端重试逻辑被异常触发。
• 在追踪中统计相同语句句柄+参数值的sp_execute请求频率，短时间内出现大量重复请求即可确认客户端侧问题。

内容的提问来源于stack exchange，提问作者Mikhail Sergievskiy