Question

我们有一个部署到生产的ASP MVC网站，这是一个相当大/受欢迎的网站，并且它获得了相当多的流量。

我们正在使用全文搜索来驱逐搜索工具。

非常随机，我在ELMAH日志中看到一堆错误，＆＃34;等待操作超时＆＃34;。当这个错误发生时，我们的许多客户似乎都在同一时间 - 例如我们在同一时间戳内记录了4或5个此错误的实例。它似乎永远不会孤立地发生。

基本上，在我们的目录页面上，我们执行了5-6个查询（例如，＆＃39;获取所有子类别＆＃39;，＆＃39;获取所有制造商＆＃39;，＆＃39; ;获取最小/最大价格范围＆＃39;，获得实际产品＆＃39;）我可以通过查看堆栈跟踪看到它是导致异常的这些方法之一。

但是，常见的是，他们会使用用户的过滤器选项并将其应用于每个查询以显示相关信息。

所以当搜索词存在时，它似乎只会失败（很少见）。例如，当客户查看没有搜索字词的目录页面时，我没有看到任何其他超时问题。

有人能指出我可能发生潜在僵局的方向吗？我们的全文索引位于View上，它从我们的产品表中提取数据。这确实每天都会使用库存信息等多次更新，但是视图中的列不会经常更改其数据。因为它是如此随意，所以很难确切地指出它发生的位置 - 当我导航到我之前可以看到之前导致异常的URL时，页面实际上加载了快速（好像搜索结果已经缓存到某种程度）。

更多信息： 视图中的54,612行（2列 - 产品ID /搜索文本）索引全文的SearchText列具有95个字符的最大行，因此它不是大量数据。在大多数情况下，目录页面需要大约600毫秒来渲染，这些查询通常需要大约20-30毫秒。然而，有时这会大量增加 - 我已经看到了执行每个查询需要大约6秒的痕迹，有时其中6个中的一个将超时并且只是非常随机的峰值。我自己从来没有真正经历过这种放缓，但我不经常浏览网站，但我们有新的遗物交易（和错误日志）显示频繁的减速和放大超时。

我们正在使用

进行查询

@Search = '("some*" AND "search*" AND "terms*")'

SELECT TOP ? * FROM (SELECT p.Score, [columns], [Rank] as SearchRank, ROW_NUMBER() OVER 
( ORDER BY p.Score * [Rank] DESC, p.Id DESC) AS row_number 
FROM Product p 
INNER JOIN Manufacturer AS m ON p.ManufacturerId = m.Id 
INNER JOIN ProductCategory pcm ON p.Id = pcm.ProductId 
INNER JOIN CONTAINSTABLE(vw_SearchProducts, FullSearch, @Search) AS FTS ON p.Id = FTS.[KEY] 
WHERE p.Deleted = ? AND pcm.CategoryId = @CategoryId) p WHERE p.row_number > ? ORDER BY p.Score * SearchRank DESC, p.Id DESC

我们的观点如下所示，ProductID为FTS键：

SELECT p.Id AS ProductId, Colour + ' ' + Size ' ' +  m.Name + ' ' + Categories AS FullSearch 
FROM Product 
INNER JOIN Manufacturer m ON m.Id = p.ManufacturerId
WHERE Deleted = 0

我们的产品表包含一些用于性能目的的非规范化数据。我们对目录页面的6个主要查询都与上面类似，但只是为符合过滤/搜索条件的产品提取不同的数据位。

我们很快就会升级到SQL Server 2016 - 不确定这是否会让事情变得更好。

干杯

Answer 1

你可以启动SQL Server Profiler并让它运行几个小时或一天，然后当你再次看到日志中的超时时，找到在那个时间记录在SQL事件探查器中的查询并检查持续时间/读取/写入列值。

也许通过这种方式，您将能够识别具有导致超时的特定参数列表的EXACT存储过程/语句。如果是这样，您将能够使用SSMS和执行计划选项卡进一步调试它。

另一个想法当然是FTS目录可能经常重建。这也可能被困，但您需要捕获确切的超时时刻，然后检查FTS目录状态是否正在重建。

升级到SQL 2012-2016时，有关FTS，特别是FTS索引更新速度的事情应该有所改进。 MS声称此类并发FTS索引更新速度提高了10倍，请参阅以下答案：Are there any Sql Server Full-Text Search (FTS) performance improvements since version 2008 R2?。

55K的数据记录真的没那么多。我们针对数百万条记录运行SQL Server FTS，并且不会超时。大多数结果都不到10秒，但这种延迟不是由FTS引起的。实际的FTS块运行速度非常快，我们需要应用于初始FTS结果的额外JOIN和过滤器会导致额外的延迟。

另一个想法是你的VIEW可能设计得很差，没有得到SQL Server缓存的执行计划或连接到自身等。为了确认这一点，我们需要查看实际的VIEW代码，尤其是JOIN/WHERE部分。

SQL Server R2 2008全文搜索导致等待超时＆＃39;随机

1 个答案: