优化select语句的执行

Question

我想优化这个选择查询：

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

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

test设计： Id int -> PRIMARY KEY， Dane1 int， Dane2 int， Dane3 int， Dane4 int， Dane5 int，

test2设计： Id int -> PRIMARY KEY， Dane6 int， Dane7 int， IdTest int，

默认索引：PK__test__7C8480AE（聚集），PK__test2__7E6CC920（聚集）

问题是： 应该添加或删除哪些索引？

- Prezes Łukasz

---

也告诉我们你的聚集索引包含哪些列。默认情况下，它们应该是主键，但也许你没有使用默认？我们无法从自动生成的聚集名称中推断出任何信息 :P - Kritner

聚集索引位于主键上：测试表中的Id和test2表中的Id。 - Prezes Łukasz

Answer 1

定义外键关系总是一个好主意。这样可以保持数据完整性，并且可以指定在删除父记录时发生的情况（例如递归删除子记录）。

外键还是查找子记录的索引的一个很好的选择。

- Tim Schmelter

Answer 2

在创建索引时，有几个要考虑的问题，比如在这种情况下：

• Dane5 > 199850的行数是多少，总共有多少行？
• 索引列是否经常更新 -> 更新速度慢。
• 是否需要大量基于关键字查找来获取查询中其他所需列的基本表？

你可以尝试像这样做：

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

是否包含Dane1取决于行数和关键查找是否存在问题

因为它是聚集索引，所以Id已经被包含在内了

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

在表格中获取Dane6和Date7这两列是否作为包含列，取决于需要执行的关键查询总量。

建议开启statistics io，以查看导致最多逻辑读取的原因，然后决定是否需要在索引中包含这些列。

- James Z

Answer 3

正如Tim所指出的那样，定义外键和在外键上定义索引是一个不错的选择。

另一个可以提高一些速度的索引——假设你的where子句总是在Dane5上——是添加一个非聚集索引在Dane5上。

- Kritner

---

我已经定义了外键并在Dane5上添加了一个非聚集索引，但是估计的子树成本比以前更糟糕，之前为4.96352，之后为4.9659，为什么？ - Prezes Łukasz

好吧，“estimated”在指标名称中 - 不一定要将其视为更多的东西。索引可能非常棘手 - 它们可以帮助某些查询，同时伤害其他查询。我一直把它们看作是更多的艺术而不是科学，尽管肯定涉及科学。只需要测试和调整。也许这只是我的想法 :D - Kritner