搜索索引列中出现次数多的值时，优化索引表的查询

Question

我有一个包含营销电子邮件事件的表格，其中一个事件可能是我们发送了电子邮件，然后收件人单击或打开了它。每次点击和打开都是一个事件。我们有 2 年的数据，大约 1.5 亿行。

我从每个收件人电子邮件地址派生电子邮件域，并且我最近在该域列上放置了一个索引。这显着提高了性能，现在我将域和地址都包含在过滤器中。耗时 10 分钟，不到 10 秒。

至少，对于大多数域来说都是如此。有 740 万个唯一的电子邮件地址，其中几乎一半是 GMAIL。如果我查询 gmail 地址，它会非常慢，甚至可能比没有索引还要慢。至少前 50 个最常见的域需要至少一分钟的时间进行基本查询。下一个最常见的域有 40 万个电子邮件地址。

其中大部分是我们所说的“免费邮件”域，我有一长串潜在的免费邮件和其他非私有域（除了 gmail 等常见的电子邮件提供商，它还包括用户注册的“一次性”域for)-- 这个列表超过 5000 个。

我有两个问题/目标。首先，只是想出一种方法来更快地查询 Gmail（我可以有选择地将其应用于其他最常见的域）。我有一些想法，这可能很糟糕，比如用电子邮件地址的第一个字母创建一个列并在上面创建一个索引。 （我不是 DBA，我之前从未在 SQL Server 上创建过索引，所以不要以为我已经想到了一些显而易见的事情。

第二个目标是更普遍地将其用于 freemail 域表中的任何内容。大多数人不需要它，但它确保任何策略都保持最新，因为该免费邮件表会以某些自动方式和手动添加域进行更新。

一个示例查询和目标。

目标：总结特定用户在一段时间内的电子邮件参与度

select contact_email, month_year, event_type, count(event_type) as events
from event_table
where email_domain = 'domain' and contact_email = 'email address'
group by contact_email, month_year, event_type

每个评论者，关于执行计划的信息，将 gmail 与不常见的东西进行对比。我可以看到它们不同，不知道如何解释。

Gmail

Uncommon domain

Answer 1

这里的问题似乎是索引搜索，它是 0%，这意味着它在一种情况下效率低，在另一种情况下没有使用。

1 - 执行

SET STATISTICS IO ON;

它将激活当前会话的统计信息。它不会持续存在，因此无需在最后将其更改为关闭。

2 - 执行您的请求并记下您在第二个 SQL 管理选项卡上看到的内容。主要是由于统计请求而出现的 IO 逻辑读取数。

3 - 如果其他进程不使用，则删除此表上的现有索引。

4 - 正如 SQL 管理中所建议的那样。您可以复制他们建议的代码（更改索引名称）

CREATE NON CLUSTERED INDEX DP_LIVE_INDEX 
ON RawContactEvent(contact_email, email_domain) 
INCLUDE (event_type)

5 - 再次执行您的请求并再次检查 IO。如果它减少了很多，你的要求会更好。 还要再次检查执行计划。索引查找应该在右侧并且接近 100%。

说明

为什么我要关注逻辑读取而不是执行时间？

逻辑读取类似于 SQL Server 在找到选择结果之前搜索的条目数。

通常需要搜索的次数越多（逻辑读取次数越多），请求的时间就越长。如果有大量的逻辑读取，则意味着您的索引没有很好地使用，因为索引将更容易定位结果。

为什么不使用执行时间？

与执行时间相反，如果请求遵循相同的执行计划（如果请求未更改，则通常是这种情况），特定请求的逻辑读取将相同。这意味着它是您请求性能的一个非常好的指标。

为什么更改索引这么少？

您的执行计划认为您当前的索引没有用。通过更改它以使其成为多列索引或包含列，这可能会更改执行计划以更好地使用它，甚至有时只是在以前不使用它时使用它。让您的请求更有效率。