为什么“IN”查询标签在sql存储过程中的成本如此之高？

如何改善我的性能问题？我有一个带有 'IN' 的 sql 查询，我猜 'IN' 会造成一些代价高昂的性能问题。但我需要索引我的 sql 查询吗？

Mysql查询：

SELECT [p].[ReferencedxxxId]  
FROM [Common].[xxxReference] AS [p]  
WHERE ([p].[IsDeleted] = 0)  
  AND (([p].[ReferencedxyzType] = @__refxyzType_0)
  AND [p].[ReferencedxxxId] IN ('42342','ffsdfd','5345345345'))

我的解决方案：（但我需要您的帮助以获得更好的建议）哪一个是正确的聚集索引或非聚集索引？

USE [xxx]
GO
CREATE NONCLUSTERED INDEX IX_NonClusteredIndexDemo_xxxId
ON [Common].[xxxReference](xxxId)
INCLUDE ([ID],[ReferencedxxxId])
WITH (DROP_EXISTING=ON, ONLINE=ON, FILLFACTOR=90)
GO

Second:

CREATE INDEX xxxReference_ReferencedxxxId_index
ON [Common].[xxxReference]  (ReferencedxxxId)[/code]

哪一个是正确的或者您有更好的解决方案？

该查询的性能问题不是使用IN操作员。
该运算符对于小型列表（例如，少于 1000 名成员）表现良好。

这里的性能瓶颈是 SQL Server 执行索引扫描而不是索引查找（成本非常高）和键查找，这占查询成本的 20%。

为了避免这两个问题，您可以添加索引IsDeleted, ReferencedxyzType and ReferencedxxxId- 大概按照这个顺序。

SQL 性能调优是一门科学，看起来有点像艺术或魔法——无论从哪种角度来看，它都需要对索引设置的理论和实践以及相关系统要求有很好的了解。

因此，我的建议是：不要试图借助互联网上陌生人的帮助自己解决问题。找一位专家进行咨询工作几个小时/几天来分析系统并帮助您对其进行微调。
在此过程中尽你所能地学习。对所有不平凡的事情提出问题。这钱花得值。