如何加快SQL表响应时间并设置正确的索引？

Question

我有一张桌子，你可以在下面看到

Listings
-----------------------------------------------------------------
ListingID            Make       Model     Year          Zipcode 

1                    BMW        325       2009          90210
2                    Mercedes   330 C     2006          33160
3    

大约2百万行。每天我都会添加新行并删除旧行。

在我的应用程序中，我通过listingid，make，make和model，make model和zipcode查询此表。

我在ListingID上有聚簇索引，在所有其他列上都有非聚簇索引。

如果我通过listingid查询表，我会得到非常快的响应。通过make，model，zipcode它很慢。例如，使用带有zipcodes的连接表返回10000条记录，大约25-30秒。

这是此表的大小

以下是我用于返回特定半径内的列表的查询示例。

1. 首先基于zipcode和radius，在函数帮助下我将zipcode插入临时表#CloseZips（需要0秒）。此过程在半径内非常快地返回zipcode 0秒。

2. 其次我加入清单表，你可以看到。这部分需要25-60秒的时间

           SELECT ListingID, Make, Model, Year, L.Zipcode, Year
       FROM Listings L WITH (NOLOCK)
       INNER JOIN  #CloseZips Z ON Z.ZipCode = L.Zipcode 
       WHERE L.Make = @Make AND L.Model = @Model AND L.IsActive = 1
       ORDER BY Z.Distance DESC
   

问题：

1. 什么是推动这种表现的正确方法 尺寸表？

2. 我是否需要在所有列上都有索引？

3. 维护这样的表格的最佳方法是什么？

Answer 1

当你没有给出实际的查询本身时，帮助你优化查询有点困难，但在这里：

• 如果您要加入表格zipcodes，请确保邮政编码列已在该表格中编入索引。

• 您还没有讨论过部分查询，这就是您如何评估一个邮政编码与另一个邮政编码的接近程度。您的查询也必须解决问题的这一部分，我猜这部分是以未编入索引的方式编写的。

• 如果您在make，model和zipcode上有单独的索引，并且在所有三列上搜索，则只会使用一个索引。您需要使用EXPLAIN工具来发现它是哪一个 - 它可能不是最佳的。

• 根据你的描述，搜索总是涉及到make，包含zipcode的搜索也总是涉及模型，我会用make和model替换你的索引单个索引（制作，模型，邮政编码）。这可以用于您的任何查询以提供索引搜索。 （您可能仍需要JOIN的zipcode索引。）

再次发布完整的SQL查询，我们可以提供更多帮助。