优化大表上的连接

Question

我试图通过访问具有约 2.5 亿条记录的表的查询来提高性能。从我对实际（未估计）执行计划的阅读来看，第一个瓶颈是如下所示的查询：

select
    b.stuff,
    a.added,
    a.value
from
    dbo.hugetable a
    inner join
    #smalltable b on a.fk = b.pk
where
    a.added between @start and @end;

有关所涉及的表和索引的定义，请进一步向下查看。

执行计划表明#smalltable 正在使用嵌套循环，并且对hugetable 的索引扫描执行了480 次（针对#smalltable 中的每一行）。这对我来说似乎是倒退，所以我试图强制使用合并连接：

select
    b.stuff,
    a.added,
    a.value
from
    dbo.hugetable a with(index = ix_hugetable)
    inner merge join
    #smalltable b with(index(1)) on a.fk = b.pk
where
    a.added between @start and @end;

有问题的索引（完整定义见下文）涵盖列fk（连接谓词）、added（在 where 子句中使用）和id（无用）按升序排列，并包括value。

然而，当我这样做时，查询从 2 1/2 分钟到超过 9 分钟。我本来希望提示会强制更有效的连接，只对每个表进行一次传递，但显然不是。

欢迎任何指导。如果需要，提供其他信息。

更新 (2011/06/02)

重新组织表上的索引后，我取得了显着的性能进步，但是在汇总大表中的数据时遇到了新的障碍。结果是按月汇总，目前如下所示：

select
    b.stuff,
    datediff(month, 0, a.added),
    count(a.value),
    sum(case when a.value > 0 else 1 end) -- this triples the running time!
from
    dbo.hugetable a
    inner join
    #smalltable b on a.fk = b.pk
group by
    b.stuff,
    datediff(month, 0, a.added);

目前，hugetable有一个聚集索引pk_hugetable (added, fk)（主键）和一个相反的非聚集索引ix_hugetable (fk, added)。

如果没有上面的第 4 列，优化器像以前一样使用嵌套循环连接，使用 #smalltable 作为外部输入，使用非聚集索引查找作为内部循环（再次执行 480 次）。我担心的是估计行 (12,958.4) 和实际行 (74,668,468) 之间的差异。这些搜索的相对成本是 45%。然而，运行时间不到一分钟。

对于第 4 列，运行时间飙升至 4 分钟。这次它以相同的相对成本 (45%) 在聚集索引上寻找 (2 次执行)，通过哈希匹配 (30%) 进行聚合，然后在 #smalltable (0%) 上进行哈希连接。

我不确定我的下一步行动。我担心的是，日期范围搜索和连接谓词都不能保证，甚至所有这些都可能会大大减少结果集。大多数情况下，日期范围只会修剪 10-15% 的记录，而fk上的内部连接可能会过滤掉 20-30%。

---

根据 Will A 的要求，结果sp_spaceused：

name      | rows      | reserved    | data        | index_size  | unused
hugetable | 261774373 | 93552920 KB | 18373816 KB | 75167432 KB | 11672 KB

---

#smalltable定义为：

create table #endpoints (
    pk uniqueidentifier primary key clustered,
    stuff varchar(6) null
);

而dbo.hugetable定义为：

create table dbo.hugetable (
    id uniqueidentifier not null,
    fk uniqueidentifier not null,
    added datetime not null,
    value decimal(13, 3) not null,

    constraint pk_hugetable primary key clustered (
        fk asc,
        added asc,
        id asc
    )
    with (
        pad_index = off, statistics_norecompute = off,
        ignore_dup_key = off, allow_row_locks = on,
        allow_page_locks = on
    )
    on [primary]
)
on [primary];

定义了以下索引：

create nonclustered index ix_hugetable on dbo.hugetable (
    fk asc, added asc, id asc
) include(value) with (
    pad_index = off, statistics_norecompute = off,
    sort_in_tempdb = off, ignore_dup_key = off,
    drop_existing = off, online = off,
    allow_row_locks = on, allow_page_locks = on
)
on [primary];

该ID字段是多余的，从以前的DBA谁坚持认为，制造品的所有表无处不应该有一个GUID，没有例外。

Answer 1

你ix_hugetable看起来很没用，因为：

• 它是聚集索引（PK）
• INCLUDE 没有区别，因为聚集索引包含所有非键列（最低叶的非键值 = INCLUDEd = 聚集索引是什么）

另外： - 添加或 fk 应该是第一个 - ID 是第一个 = 没有多大用处

尝试将聚集键更改为(added, fk, id)并删除ix_hugetable。你已经试过了(fk, added, id)。如果不出意外，您将节省大量磁盘空间和索引维护

另一种选择可能是尝试使用表顺序 boh 方式和没有 JOIN/INDEX 提示的 FORCE ORDER 提示。我尽量不亲自使用 JOIN/INDEX 提示，因为您删除了优化器的选项。许多年前，有人告诉我（与 SQL Guru 的研讨会），当您拥有大表 JOIN 小表时，FORCE ORDER 提示会有所帮助：YMMV 7 年后...

哦，让我们知道 DBA 住在哪里，以便我们可以安排一些打击乐调整

编辑，6 月 2 日更新后

第 4 列不是非聚集索引的一部分，因此它使用聚集索引。

尝试将 NC 索引更改为 INCLUDE 值列，这样它就不必访问聚集索引的值列

create nonclustered index ix_hugetable on dbo.hugetable (
    fk asc, added asc
) include(value)

注意：如果值不可为空，那么它在COUNT(*)语义上是一样的。但是对于 SUM 它需要实际值，而不是存在。

例如，如果您更改COUNT(value)为COUNT(DISTINCT value) without更改索引，它应该再次中断查询，因为它必须将值作为值处理，而不是作为存在处理。

查询需要 3 列：已添加、fk、值。前 2 个被过滤/加入，键列也是如此。值只是被使用，所以可以被包括在内。覆盖索引的经典用法。