优化select的执行答案

【问题标题】：Optimize the execution of select优化select的执行
【发布时间】：2015-08-31 03:22:09
【问题描述】：

我想优化这个选择：

Select Dane1, Dane5, Dane6, Dane7 FROM Test
INNER JOIN Test2 ON Test.Id=Test2.IdTest
WHERE Dane5 > 199850

我的数据库有2个表test，test2：

测试设计： Id int -> 主键， Dane1 int, Dane2 整数， Dane3 int, Dane4 int, Dane5 int,

test2 设计： Id int -> 主键， Dane6 int, Dane7 int, IdTest 整数，

默认索引： PK__test__7C8480AE(Clustered)、PK__test2__7E6CC920(Clustered)

问题是：要附加或删除哪些索引？

【问题讨论】：

【解决方案1】：

创建索引时需要考虑的事项很少，例如在这种情况下：

你可以试试这样的：

Create index test_xxx on test (Dane5) include (Dane1)

包含 Dane1 的天气取决于行数以及键查找是否导致问题

ID 已包含，因为它是聚集索引

Create index test2_yyy on test2 (IdTest) include (Dane6, Dane7)

将 Dane6 和 Date7 作为包含列的天气在这里还取决于需要对表进行的键查找总数

您应该打开统计 io 以查看导致最多逻辑读取的原因，以及是否需要索引中包含的列。

【讨论】：

【解决方案2】：

正如 Tim 所指出的，外键和在外键上定义的索引是一个很好的调用。

一个额外的索引可以为您带来额外的速度 - 假设您的 where 子句总是在 Dane5 上 - 是在 Dane5 上添加一个非聚集索引

【讨论】：

我已经在 Dane5 上定义了外键并添加了一个非聚集索引，但是估计的 subtreecost 比之前更差，之前：4,96352，之后：4,9659 为什么？
好吧...“估计”是指标的名称 - 不必将其视为更多。 Indeces 可能非常棘手 - 它们可以帮助一些查询，同时伤害其他查询。我一直认为它们更像是一门艺术而不是科学，尽管其中肯定涉及科学。只需进行测试和调整。也许那只是我：D

【解决方案3】：

定义foreign-key relationships 总是一个好主意。这样，您可以保持数据完整性，并且可以指定删除父记录时会发生什么（例如递归删除子记录）。

外键也是index 快速查找子记录的理想选择。

【讨论】：