这种情况我可太熟了！核心问题出在SQL Server查询优化器对表变量的“偏见”上，具体原因和解决办法给你掰扯清楚：

主要原因 #

1. 表变量没有统计信息 #

SQL Server默认不会为表变量收集统计信息——优化器根本不知道你的表变量里有几条数据（哪怕你只插了2条，它也可能默认按“海量数据”来估算）。这种信息缺失会让优化器生成完全错误的执行计划，比如明明用索引seek就能搞定，结果它选了全表扫描，速度自然拉胯。

而硬编码值的时候，优化器能直接看到IN (1,2)里只有2个值，立刻就能判断出最优的查询路径，执行起来当然快。

2. 基数估计严重不准 #

因为没有统计信息，优化器对表变量的基数（行数）估计完全靠猜。如果你的主表数据量很大，优化器可能会选择低效的连接方式（比如哈希连接代替嵌套循环），或者跳过合适的索引，直接导致查询变慢。

解决办法 #

给你几个实用的方案，按优先级排序：

• 改用临时表代替表变量
  临时表（#temp）会自动生成统计信息，优化器能准确获取数据量，生成高效的执行计划。比如把DECLARE @Ids TABLE (...)改成CREATE TABLE #Ids (...)，用完记得DROP TABLE #Ids，或者让SQL Server自动清理。

• 给查询加OPTION(RECOMPILE)
  在查询语句末尾加上这个选项，让优化器重新编译查询——这时候它会读取表变量的实际数据量，生成适配的执行计划。示例：

  DECLARE @Ids TABLE (Id INT);
  INSERT INTO @Ids VALUES (1,2);
  
  SELECT * FROM YourBigTable 
  WHERE Id IN (SELECT Id FROM @Ids)
  OPTION(RECOMPILE);
  

• 手动更新表变量统计信息（SQL Server 2019+）
  如果你必须用表变量，SQL Server 2019及以后版本支持手动更新统计信息：

  UPDATE STATISTICS @Ids;
  

  不过这个效果不如临时表稳定，只适合应急场景。

• 调整兼容性级别或跟踪标志
  如果是SQL Server 2014及以后，把数据库兼容性级别设为120+，或者在查询里加OPTION(QUERYTRACEON 4138)来改善基数估计，但全局跟踪标志要谨慎使用，最好先测试。

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