为什么没有索引这个查询会更快？

Question

我继承了一个新系统，我正在尝试对数据进行一些改进。我正在尝试改进这张表，但似乎无法理解我的发现。

我有以下表结构：

CREATE TABLE [dbo].[Calls](
    [CallID] [varchar](8) NOT NULL PRIMARY KEY,
    [RecvdDate] [varchar](10) NOT NULL,
    [yr] [int] NOT NULL,
    [Mnth] [int] NOT NULL,
    [CallStatus] [varchar](50) NOT NULL,
    [Category] [varchar](100) NOT NULL,
    [QCall] [varchar](15) NOT NULL,
    [KOUNT] [int] NOT NULL)

该表约有 220k 条记录。我需要返回日期大于特定日期的所有记录。在本例中为 2009 年 12 月 1 日。该查询将返回大约 66k 条记录，运行时间大约为 4 秒。从我过去开发过的系统来看，这似乎很高。特别是考虑到表中的记录很少。所以我想缩短这个时间。

所以我想知道有什么好方法可以减少这种情况？我尝试向表中添加日期列并将字符串日期转换为实际日期列。然后我在该日期列上添加了一个索引，但时间保持不变。鉴于没有那么多记录，我可以看到表扫描如何快速，但我认为索引可以缩短时间。

我还考虑过只查询月份和年份列。但我还没有尝试过。如果可能的话，希望将其保留在日期列之外。但如果没有我可以改变它。

任何帮助表示赞赏。

编辑：这是我尝试运行并测试表速度的查询。我通常会列出这些列，但为了简单起见，我使用了 * :

SELECT *
FROM _FirstSlaLevel_Tickets_New
WHERE TicketRecvdDateTime >= '12/01/2009'

编辑 2: 所以我提到我曾尝试创建一个包含日期列的表，其中包含 recvddate 数据，但作为日期而不是 varchar。这就是上面查询中的 TicketRecvdDateTime 列。我针对该表运行的原始查询是：

SELECT *
FROM Calls
WHERE CAST(RecvdDate AS DATE) >= '12/01/2009'

Answer 1

您可能会遇到 SQL Server 中所谓的临界点。即使您在列上有适当的索引，如果返回的预期行数超过某个阈值（“临界点”），SQL Server 仍可能决定执行表扫描。

在您的示例中，这似乎很可能，因为您正在转动数据库中行数的 1/4。以下是解释这一点的好文章：http://www.sqlskills.com/BLOGS/KIMBERLY/category/The-Tipping-Point.aspx

Answer 2

SELECT * 通常性能较差。

要么索引将被忽略，要么您最终将在聚集索引中进行键/书签查找。没关系：两者都可能运行得很糟糕。

例如，如果您有此查询，并且 TicketRecvdDateTime 上的索引 INCLUDEd CallStatus，那么它很可能会按预期运行。这将是 覆盖

SELECT CallStatus
FROM _FirstSlaLevel_Tickets_New
WHERE TicketRecvdDateTime >= '12/01/2009'

这是对 Randy Minder 答案的补充：键/书签查找对于少数行来说可能足够便宜，但对于大量表数据来说则不然。

Answer 3

您的查询在没有索引的情况下会更快（或者更准确地说，在有或没有索引的情况下速度相同），因为 RecvdDate 上的索引将始终在 CAST(RecvdDate AS DATE) >= '12/01/2009' 等表达式中被忽略。这是一个不可SARG 的表达式，因为它需要通过函数转换列。为了使此索引事件被考虑，您必须准确在正在索引的列上表达您的过滤条件，而不是基于基于该列的表达式。这将是第一步。

还有更多步骤：

• 删除日期的 VARCHAR(10) 列并将其替换为适当的 DATE 或 DATETIME 列。将日期和/或时间存储为字符串充满了问题。不仅为了索引，还为了正确性。
• 经常在基于列的范围内扫描的表（大多数此类调用日志表都是如此）应该按该列聚集。
• 您不太可能真正需要 yr 和 mnth 列。如果您确实需要它们，那么您可能需要它们作为计算列。

。

CREATE TABLE [dbo].[Calls](
    [CallID] [varchar](8) NOT NULL,
    [RecvdDate] [datetime](10) NOT NULL,
    [CallStatus] [varchar](50) NOT NULL,
    [Category] [varchar](100) NOT NULL,
    [QCall] [varchar](15) NOT NULL,
    [KOUNT] [int] NOT NULL,
    CONSTRAINT [PK_Calls_CallId] PRIMARY KEY NONCLUSTERED ([CallID]));

CREATE CLUSTERED INDEX cdxCalls ON Calls(RecvDate);

SELECT *
FROM Calls
WHERE RecvDate >= '12/01/2009';

当然，表和索引的正确结构应该是仔细分析的结果，考虑所涉及的所有因素，包括更新性能、其他查询等。我建议您首先浏览所有包含的主题在设计索引中。

Answer 4

您可以更改您的查询吗？如果需要很少的列，您可以更改 SELECT 子句以返回更少的列。然后，您可以创建一个覆盖索引，其中包含引用的所有列，包括 TicketRecvdDateTime。

您可以在 TicketRecvdDateTime 上创建索引，但您可能无法避免 @Randy Minder 讨论的临界点。但是，对较小索引（小于表扫描）的扫描将返回较少的页面。

Answer 5

假设 RecvdDate 是您正在讨论的 TicketRecvdDateTime：

如果字段类型为 DATE，SQL Server 仅比较单引号中的日期。您的查询可能将它们与 VARCHAR 进行比较。尝试添加一行“99/99/0001”，看看它是否显示在底部。

如果是这样，则您的查询结果不正确。将类型更改为日期。

请注意，VARCHAR 的索引不好，而 DATETIME 可以。

检查查询计划以查看其是否使用索引。如果数据库与可用 RAM 相比较小，它可能会简单地进行表扫描并将所有内容保存在内存中。

编辑：在看到您的 CAST/DATETIME 编辑时，让我指出从 VARCHAR 解析日期是一项非常昂贵的操作。您已执行此操作 22 万次。这会降低性能。

此外，您不再检查索引字段。与涉及索引字段的表达式的比较不使用索引。