UDTT变量仅在rpc:completed事件显示unknown，关联SQL查询性能异常排查

现象总结 #

• 相同C#代码执行的SQL查询，多数情况下RPC事件中UDTT变量明确声明为dbo.TypeTableGuid，性能正常；
• 少数请求中，RPC:Completed事件里UDTT变量被标记为unknown，对应查询逻辑读暴增、执行时长超长；
• 直接在SSMS复制执行慢查询语句，无unknown问题，性能恢复正常。

可能根源 #

1. 查询优化器类型识别失败：当变量被标记为unknown时，SQL Server无法获取该UDTT的统计信息和结构定义，优化器只能生成低效执行计划（比如用全表扫描代替索引匹配），直接导致逻辑读飙升。
2. ADO.NET参数传递偶发异常：
   • 连接池复用可能导致连接残留的参数元数据污染后续请求，使UDTT类型未被正确识别；
   • 特定.NET版本的SqlClient驱动存在UDTT参数类型推断bug，偶发导致类型丢失。
3. SQL Server元数据缓存异常：UDTT的元数据缓存出现损坏，导致部分请求无法正确解析类型，显示为unknown。

排查&解决建议 #

• 显式指定UDTT参数类型：在C#代码中不要依赖自动参数推断，手动指定参数类型和UDTT名称，确保传递准确：

  var udttParam = new SqlParameter("@Listeguid", SqlDbType.Structured)
  {
      TypeName = "dbo.TypeTableGuid",
      Value = yourGuidDataTable // 填充好的UDTT数据
  };
  sqlCommand.Parameters.Add(udttParam);
  

• 排查连接池问题：临时在连接字符串中添加Pooling=false，禁用连接池后观察问题是否消失。如果消失，说明是连接池复用导致的参数上下文污染，可以考虑重置连接池或调整连接池配置。
• 升级驱动/框架版本：如果使用的是.NET Framework 4.x或旧版Microsoft.Data.SqlClient，升级到最新稳定版，修复已知的参数传递bug。
• 验证UDTT元数据：执行以下SQL确认UDTT存在且元数据正常：

  SELECT name, schema_id, type_table_object_id 
  FROM sys.table_types 
  WHERE name = 'TypeTableGuid';
  

  若元数据异常，备份后重新创建UDTT。
• 强制执行计划重新编译：作为临时 workaround，在查询末尾添加OPTION (RECOMPILE)，让优化器每次生成针对当前参数的执行计划，避免糟糕的计划复用：

  SELECT * from table1 inner join @Listeguid L on L.Value = table1.id
  OPTION (RECOMPILE)
  

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