SQL查询在随机时间很长

我在SQL Server 2005上的一个非常小的表（< 10行，5列）上运行一个非常简单的查询，通常它会立即返回结果，但有时需要很长时间才能完成（如5-10s）。我知道，我们的服务器负载很重，这可能是原因（因为我不认为它可能会发生，因为锁 - 没有人写入该表） - 但我需要以某种方式找到瓶颈。SQL查询在随机时间很长

关于如何才能找到确切的服务器资源，这使得这样简单的查询运行这么久的任何建议？

来源

2011-04-07 Hassan

您可以监视SQL Server正在使用的客户端连接数吗？也许某些最大限制正在受到打击，所以传入的客户端连接必须等待现有连接才能获得释放，通过超时。 – 2011-04-07 13:59:53

你发现了什么是瓶颈吗？ – broadband 2015-11-19 18:15:36

你需要的唯一东西就是分析。您需要了解内存，输入/输出和处理器。您需要知道这三个中的哪一个导致服务器变慢。有很多产品可以做到这一点（甚至还有一个安装了Windows的性能监视器）。

不要“想”它，你需要看到数据以了解基本问题。

来源

2011-04-07 14:01:12 Ali

在SSMS中，在对象资源管理器中右键单击连接的服务器，然后选择活动监视器。

在那里您可以看到最近昂贵的查询和其他性能数据。

来源

2011-04-07 14:01:53 MadBender

您不需要写入表中就可以锁定它。您可以尝试修改其中一条SELECT语句以使用WITH (NOLOCK)另一个非常缓慢并且加入到此表中的语句（插入/更新/删除）可能会锁定它。

来源

2011-04-07 14:03:36 openshac

你是什么意思的另一个查询，使加入到这张表。如果您只对此表执行选择语句，则不会被锁定。没有锁定获得。 – broadband 2015-11-19 18:12:12

编辑我的答案以“语句”替换“查询”一词。谢谢。 – openshac 2015-11-21 16:11:05

除了运行探查，并检查page life expectancy也buffer cache hit ratio参见：Use sys.dm_os_performance_counters to get your Buffer cache hit ratio and Page life expectancy counters

它也可以（但你必须测试）是什么情况是，你正在寻找得到了圈外的数据在RAM缓存，现在它已经从磁盘获取它，这将需要更长的时间，当你以后再运行它第二次将再次快速

您可以通过统计运行检查IO ON

SET STATISTICS IO ON 

select * ..your query

是

你应该看到类似的东西

Table'TableNAme'。扫描计数1，逻辑读取4，物理由从RAM丢弃数据读取2

如果看到physical reads高于0，它抓住它从磁盘

可以验证这一点（未生产）

DBCC freeproccache 
DBCC DROPcleanbuffers

现在当你运行一个查询两次，你会看到这样的事情，第一次运行时会从盘，第二从RAM

Table'TableNAme'。扫描计数1，逻辑读取4,物理读取2

表'TableNAme'。扫描计数1，逻辑读取4,物理读取0

来源

2011-04-07 14:05:42 SQLMenace

SQL查询在随机时间很长

回答

相关问题