Question

“我们应该忘记小的效率，大约97％的时间说：过早的优化是所有邪恶的根源。” （唐纳德克努特）我的SQL表不太可能包含超过几千行（并且那些是大的！）。 SQL Server数据库引擎优化顾问将数据量视为无关紧要。所以我甚至不应该考虑在这些表上放置显式索引。正确的吗？

Answer 1

索引的价值在于超速读取。例如，如果您根据日期列中的一系列日期执行大量SELECT，则在该列上放置索引是有意义的。当然，通常您可以在任何重要频率上加入任何列上的索引。效率增益还与典型记录集的大小与记录数量的比率有关（即，从索引中获取20/2000记录的好处多于获取90/100记录的好处）。对未编制索引的列的查找本质上是线性搜索。

索引的成本来自写入，因为每个INSERT还需要对每个列索引进行内部插入。

因此，答案完全取决于您的应用程序 - 如果它类似于动态网站，其中读取的数量可以是写入的100倍或1000倍，并且您正在基于数据列进行频繁，不同的查找，索引可能很有益。但是如果写入数量大大超过读取次数，那么您的调优应该集中在加速这些查询。

在JOIN / WHERE列上使用和不使用索引来识别和评估少数应用程序最常用的操作只需要很少的时间，我建议你这样做。监控生产应用程序并确定最昂贵，最常见的查询，并将优化工作集中在这两组查询的交集上（这可能意味着索引或完全不同的内容，例如分配更多或更少的内存，这也很聪明）查询或加入缓存）。

Answer 2

Knuth的明智之词不适用于索引的创建（或不是），因为通过添加索引，您不直接优化任何内容：您提供的是DBMS优化器可能的索引用于优化某些查询。事实上，你可以更好地争辩说决定不来索引一个小表是过早的优化，因为这样做会限制DBMS优化器的选项！

不同的DBMS将根据各种因素（包括表格大小）选择是否对列进行索引，从而有不同的指导原则，应该考虑这些因素。

是数据库中过早优化的一个例子：在任何基准测试表明规范化数据库实际上存在任何性能问题之前，“对性能进行非规范化”。

Answer 3

将为唯一约束索引主键列。我仍然会索引所有外键列。如果索引不相关，优化器可以选择忽略您的索引。

如果您只有一点数据，那么插入/更新的额外成本也不应该很高。

Answer 4

这取决于。该表是参考表吗？

有一千行的表没有索引，结果表扫描可以区分一个相当简单的操作，将用户延迟5分钟而不是5秒。我已经看到了这个问题，使用的是SQL Server以外的DBMS。

通常，如果表是参考表，则对其进行更新将相对较少。这意味着更新索引的性能损失也相对较少。如果优化程序通过索引，则优化程序的性能损失可以忽略不计。存储索引所需的空间也可以忽略不计。

如果声明主键，则应该获得该键的自动索引。自动索引几乎总能让你足够好以证明其成本合理。留在那里。如果创建没有主键的引用表，则在设计方法中还存在其他问题。

如果您对主键以外的某些列进行频繁搜索或频繁加入，则额外的索引可能会收回成本。除非是问题，否则不要解决这个问题。

以下是一般经验法则：使用DBMS的默认行为，除非您找到理由不这样做。对您而言，任何其他事情都是过早关注优化的问题。

Answer 5

绝对错误。 100％不正确。不要放置一百万个无意义的索引，但是你确实想要一个主键（在大多数情况下），并且你确实希望它能正确地进行CLUSTERED。

原因如下：

SELECT * FROM MySmallTable <-- No worries... Index won't help

SELECT
    *
FROM
    MyBigTable INNER JOIN MySmallTable ON... <-- Ahh, now I'm glad I have my index.

这是一个很好的规则。

“由于我有一个TABLE，我可能会想要在某个时候查询它...如果我要查询它，我可能会以一致的方式这样做... “＆lt; - 那就是你应该如何索引表格。

编辑：我正在添加这一行：如果你有一个具体的例子，我会告诉你如何索引它，以及你将从中获得多少节省。请提供一个表格，以及您计划如何使用该表格的示例。

Answer 6

我建议您遵循关于索引的常规规则，这大致意味着“在您在查询中使用的那些列上创建索引”。

这样一个小型数据库可能听起来没必要。正如其他人已经说过的那样：只要你的数据库保持你所描述的那么小，无论如何查询都会足够快，而且并不真正需要索引。它们甚至可以减慢插入和更新速度，但除非您有非常具体的要求，否则对于这么小的数据库来说无关紧要。

但是，如果数据库增长（哪些数据库有时会有这种趋势），您不必记得将索引添加到那个您可能已经忘记的旧数据库中。也许它甚至安装在您的客户身上，您无法修改它！

我想我所说的是：索引应该是数据库设计的一个自然组成部分，它是缺少索引的优化，是否过早。

Answer 7

如果行的宽度较窄，并且在10-20个8K页面上有几千行，则即使您创建索引，SQL优化器也不太可能选择使用索引。

Answer 8

如果你必须放入索引:) 有时候放索引实际上会损害性能，这取决于表的用途......
因此，换句话说，您可以考虑在必要时将索引放在表上，这可以通过分析应用程序来确定。

Answer 9

使用UNIQUE约束时，通常会隐式创建索引。在这种情况下，我不会试图避免使用它们！

Answer 10

作为一般经验法则，最好避免使用较小的索引，因为它们通常不会被使用。

但有时他们可以提供巨大的推动力，因为我概述了here。

Answer 11

我想在表的主键上有一个自动索引，在查询数据较少的表时应该足够了。

因此，如果有一个小数据集需要处理，可以避免使用显式索引。

Answer 12

即使您有索引，SQL Server也可能根本不使用它，具体取决于该表的统计信息。如果您计划为每年最多运行几次的报告添加索引，请记住，添加索引的INSERT / UPDATE惩罚将始终有效。在添加索引之前，请问自己是否值得性能损失。

Answer 13

你必须要理解，基于查询可以完成两个查找，一个到索引中以获取指向行的指针，在行本身旁边。如果正在查询的数据位于索引列中，则可能不需要额外的步骤。

即使优化器追踪索引，完全有可能对数据进行双重倾斜可能会更慢。我们是否关心取决于应用程序分析和最终解释计划。

小桌子上没有索引？

13 个答案: