sql-server - 我应该在 SQL Server 中为位字段建立索引吗？

Question

我记得曾经读到过，对低基数(少量不同值)的字段建立索引并不值得做。我承认我对索引的工作原理了解不够，无法理解其中的原因。

如果我有一个包含 1 亿行的表，并且我正在选择位字段为 1 的记录，该怎么办？假设在任何时间点，只有少数记录的位字段为 1(而不是 0)。是否值得为该位字段建立索引？为什么？

当然，我可以测试它并检查执行计划，我会这样做，但我也对其背后的理论感到好奇。基数什么时候重要，什么时候不重要？

Answer 1

考虑一下 SQL 中的索引 - 索引实际上是指向其他内存块的内存块(即指向行的指针)。索引被分成多个页面，以便可以根据使用情况从内存中加载和卸载索引的某些部分。

当您请求一组行时，SQL 使用索引比表扫描(查看每一行)更快地查找行。

SQL 有聚集索引和非聚集索引。我对聚集索引的理解是它们将相似的索引值分组到同一页面中。这样，当您请求与索引值匹配的所有行时，SQL 可以从内存的聚集页返回这些行。这就是为什么尝试对 GUID 列进行聚类索引是一个坏主意 - 您不要尝试对随机值进行聚类。

当您对整数列建立索引时，SQL 的索引包含每个索引值的一组行。如果范围是 1 到 10，那么您将有 10 个索引指针。根据有多少行，可以进行不同的分页。如果您的查询查找与“1”匹配的索引，然后在 Name 包含“Fred”的地方(假设 Name 列没有索引)，SQL 会非常快速地获取与“1”匹配的行集，然后进行表扫描以查找其余行。

所以 SQL 真正做的是尝试减少它必须迭代的工作集(行数)。

当您对位字段(或某个窄范围)建立索引时，只会将工作集减少与该值匹配的行数。如果匹配的行数较少，则会大大减少您的工作集。对于大量具有 50/50 分布的行，与保持索引最新相比，它可能会给您带来很少的性能增益。

每个人都说要测试的原因是因为 SQL 包含一个非常聪明且复杂的优化器，如果它认为表扫描更快，则可能会忽略索引，或者可能使用排序，或者可能以它喜欢的方式组织内存页。