C# 使用参数化查询时，SQL查询速度非常慢

我对表格有个疑问

SELECT DISTINCT Str,Score 
FROM Tab 
WHERE Str in ('Str1', 'Str2', 'Str3') AND Type = 0

表架构是

  Str - varchar(8000)  
  Score - int  
  Type - bit  

我还有一个关于

Str

的索引，其中包括

Type

和

Score

中的

中的字符串数不同

当我从C#构造一个直接查询时，它实际上是即时的

当我使用参数化查询（使用这里的方法）时，它会变得非常慢——原始查询只需不到一秒钟的时间。这是超时

查看SQL profiler和SSM，速度缓慢似乎是由于将语句包装在
exec sp_executesql
中导致索引扫描而不是搜索。直接查询使用前面提到的索引。使用
sp_executesql
，索引不会

我的怀疑正确吗？有没有办法解决这个问题


除了Martin指定的根本原因之外，解决方案是使用

command.Parameters[i].DbType=DbType.AnsiString

这迫使varchar而不是nvarchar
从您的问题中不清楚您采取了什么样的参数化方法；你提到的问题显示了不同的方法

如果使用表值参数解决方案，可能会遇到SQL Server在不知道TVP参数中的项数的情况下创建的缓存查询计划。默认情况下，IIRC假设有10000个条目，这将解释索引扫描而不是搜索

也就是说，尝试在参数化查询的末尾添加
选项（重新编译）
提示，这将使SQL Server能够使用（当时已知的）项目计数重新编译查询。
问题不在于参数化查询

根据指定在
子句中的

中硬编码的值时，最好对#值进行良好的估计：

---

在in子句中包含大量值（数千个）可能会消耗资源并返回错误8623或8632。要解决此问题，请将in列表中的项目存储在表中

参数必须是

varchar

而不是

nvarchar

否则查询将被有效地执行

WHERE IMPLICIT_CAST(Str AS NVARCHAR(4000)) in (@P1,@P2,@P3) AND Type = 0

---

这会影响索引的使用。

尝试使用

sqlprofiler

可能会让您知道它需要改进的地方！

exec sp_executesql

来自哪里？那么您正在使用的参数化代码到底是如何的？@huMptyduMpty已经在那里查看过了（错误地将其称为跟踪），基本上我看到当参数化查询执行时，索引没有被使用，并且它使用了错误的index@Lucero当我从C#执行参数化查询时会出现这个问题，参数的数据类型是什么？另外，为什么

Str

同时

varchar（8000）

和索引？无论如何，如果您尝试插入一个大于900字节的值，它将失败。我在参数化查询的末尾使用了one by Mark（我链接到的那个）添加选项（重新编译），效果非常好--谢谢Lucero！我现在必须学习所有这些奇怪的技巧，从Oracle到SQL Server:pGood文章更深入地描述选项（重新编译）：-1问题中绝对没有任何东西表明他们遇到了这个问题。我在中有多达几十个值clause@MartinSmith-你有什么建议（假设没有严重到导致错误的程度）？“in中的字符串数不一样”不是说明了这一点吗？。