【发布时间】：2026-01-24 20:15:02
【问题描述】：
- 何时为表设置索引，在创建表期间或在性能调整期间？
- 索引的优缺点是什么？
【问题讨论】：
标签： sql sql-server-2005 indexing
【发布时间】：2026-01-24 20:15:02
【问题描述】：
许多（大多数？）DBMS 使用索引来支持唯一约束。始终创建索引以强制执行唯一约束；它们（约束）对于数据库的正确操作至关重要。
如果您可以选择如何在多个列上创建索引，则通常将查询中始终引用的列放在其他字段之前。如果前导列也有一定的选择性，这是最好的。
在获得唯一性所需的约束后，请考虑实施参照完整性所需的约束。它们通常也是由 DBMS 授权的。同样，你不能让你的数据库处于不完整的状态——它是一个逻辑系统，如果它包含谬误，你可以从中证明任何东西，但这没有帮助。
在处理（索引）唯一性和参照完整性约束之后，您可能会或可能不会从其他一些约束中受益。仔细选择，并尽可能少地添加额外的东西（零是一个好数字）。每个索引都会减慢更新操作（UPDATE、INSERT、DELETE）并占用存储空间。其目的是通过加快查询速度来赢得一席之地。但是，不要忘记优化器必须考虑每个索引以及它在回答查询时是否有用，因此索引也会减慢优化器的速度（尽管您可能很难衡量这种效果）。
当您添加索引时，将它们添加到选择性列（不是包含“M”和“F”的“sex”，但可能包含 1900 到 2010 之间的出生日期的“dob”，或者甚至可能比这更不同的值. 考虑额外的列是否有助于回答更多的查询。一些 DBMS（例如 DB2）为索引提供了额外的列，这些列不是唯一性约束的一部分，但提供了查询中经常使用的列。这些可以允许索引-仅扫描（不需要访问表数据，因为所需的值都在索引中）。
还有很多可以说的，但这涵盖了很多领域。
- 尽可能少的索引 - 最好不要额外的。
【讨论】：
需要达到一个平衡点。如果您知道将查询一个表并且 FieldA 将成为 where 子句的一部分，并且它是一个高度可选择的字段（google 基数），那么它是抢先调优的理想选择。
不要在各种字段上抛出索引，因为您认为这是有道理的，必须知道这些事情。过早的调整/优化是智者曾经说过的万恶之源。在这种情况下，索引会影响插入/更新性能，因为不仅表数据需要更新，索引也需要更新。
附注 - 对于一些大型数据加载，人们通常会删除索引，执行加载然后重新创建索引，以便加载执行得更快。
至于优点和缺点 - 这是一个很大的话题。我建议你从这里开始。
【讨论】：
通常，您在创建表时设置索引。在此阶段，您应该已经很好地了解了您的数据将如何被查询，以及哪些字段最常用作查询条件。
在性能调优期间，一般建议将明显的索引放在适当的位置。在此阶段，您将能够了解是否存在未有效使用的索引，或者是否存在索引可以提高性能的查询。在性能调整期间删除或添加新索引没有什么能阻止您。
【讨论】：
我会添加“明显”索引，即在您知道将在创建表时查询的字段上，然后根据需要添加其他索引作为曲调的一部分。最好先使用较少的索引，然后再了解系统的性能和使用情况 - 您的朋友会听到配置文件。
优势 - 更快的访问（在使用索引时），以及执行某些业务逻辑的能力，例如没有重复。
缺点 - 表格占用更多空间，插入行更慢（可能更慢），触及关键字段的更新更慢
【讨论】：
-
@MrTelly 你能说一下“明显”的索引是什么吗？
-
就像我说的，你知道的字段也将被查询任何外键字段。