简单 SELECT 的性能不佳答案

【问题标题】：Bad performance on a simple SELECT简单 SELECT 的性能不佳
【发布时间】：2018-10-08 14:37:51
【问题描述】：

我有一个非常简单的 SELECT 语句，它比它应该花费的时间多得多。它只从一个没有 JOIN、没有计算列的表中进行选择。该表不是特别大（300 万行，小行大小）。我有一个合适的查询索引（SQL Profile 显示它正在被使用），它最近被重建（每周）并且统计信息是最新的（每天）。我曾尝试将 SELECT 放入存储过程，但这无济于事。我也尝试过使用 WITH (NOLOCK)，但没有太大的改进。它经常被查询但不是很频繁——它不在我们应用程序的前 50 个查询中。结果大小通常为 1 - 5 行。此表上的 INSERT / UPDATE 流量也相当多，略低于 SELECT 流量。

带有 SELECT 的存储过程是：

CREATE PROCEDURE [dbo].[fetchcurrentichecklistitemanswers] @p_ichecklistitemid Int
AS

DECLARE @ichecklistitemid Int = @p_ichecklistitemid

SELECT * FROM ichecklistitemanswers WITH (NOLOCK) WHERE ichecklistitemid = @ichecklistitemid AND status = 2 ORDER BY ordering ASC

GO

还有什么可能会减慢这样一个简单的 SELECT 的速度吗？

[edit -- added execution plan] 查询在 Management Studio（即时）中运行速度很快，但在应用程序中，查询时间平均超过 1 秒。

【问题讨论】：

您是否尝试过使用执行计划进行查询？
我们需要查看执行计划。也许没有关于 ichecklistitemid 或状态的索引？ order by 也会减慢它的速度。可能是一张巨大的桌子......等等
参数嗅探可能有问题，可以尝试添加OPTION (RECOMPILE)
NOLOCK 不是一个神奇的快速按钮。它带有一些非常严重的包袱，大多数人并不完全理解。 blogs.sentryone.com/aaronbertrand/bad-habits-nolock-everywhere

标签： sql-server tsql query-performance

【解决方案1】：

您可以在该列上添加索引：

CREATE INDEX idx ON ichecklistitemanswers(ichecklistitemid)
INCLUDE(status, ordering) WHERE status=2;

【讨论】：