主页 / dba / 问题 / 327548
Accepted
nam
Asked: 2023-05-26 07:02:21 +0800 CST

我是否需要在只有几列的表上使用聚簇索引？

  • 772

桌子：

Address (
 AddressID bigint, 
 Street VARCHAR(150), 
 City VARCHAR(200), 
 State CHAR(2), 
 State VARCHAR(5)
)

表大小：5GB，6000 万行。

AdressID是顺序的。

备注：使用的 95-98% 的查询与以下查询相同，但子句中的 AddressID 范围有所不同WHERE：

SELECT AddressID,  Street , City, State, State 
 WHERE AddressID > someNumber AND AddressID < anotherNumber

问题：是否值得在 上创建聚簇索引AddressID？还是会适得其反，因为至少 95% 的查询会选择表的所有列？

根据以上信息，是否还有其他好的选择来创建有助于提高上述查询性能的任何索引？我想创建一个覆盖索引，但那不是像表扫描一样吗，因为它将包括表的所有列？

sql-server

1 个回答

  1. Best Answer

    对于 Erik 的观点，当您必须对表应用任何类型的谓词（例如JOIN, WHERE,HAVING子句）时，索引是GROUP BY值得拥有的，并且在使用or时也很有用ORDER BY，无论您是否对表应用谓词。原因是，索引在逻辑上对定义其键的数据进行排序——通常使用 B 树数据结构。将索引想象成电话簿，它是经过排序的。

    聚集索引在逻辑上对表数据本身进行排序。非聚集索引存储该索引中定义的数据副本，并根据其键对该数据副本进行排序。由于聚簇索引本质上是表，因此所有列在该索引中的叶级节点上都隐式可用。它基本上是免费赠品，因为它没有在表中存储数据的副本，它就是表。

    这使得聚集索引定义(AddressID)非常适合您的用例，因为您需要表中的所有列，并且您正在使用WHERE始终引用该字段的子句过滤表。索引允许 SQL 引擎直接查找启动WHERE子句值范围的 B 树节点。如果没有一个，则需要首先扫描整个表的 6000 万行，然后才能将其过滤到仅包含您的子句WHERE需要的行。

    在您的表上使用聚簇索引的另一个重要好处是，如果您以后需要添加额外的非聚簇索引来支持任何其他对您的表进行谓词的情况。您可以通过不包括查询正在访问的所有列来保持其中一些非聚集索引的精简SELECT。这是因为 SQL 引擎在通过覆盖该其他谓词的非聚集索引过滤行之后，可以利用聚集索引相当高效地获取那些缺失的字段。每个非聚簇索引都隐式存储聚簇索引键，以便它可以轻松查找它没有存储的任何列。此执行步骤称为Key Lookups。取决于返回/需要做的行数Key Lookups与表/索引的宽度相比，有时将这些字段的额外副本仅存储在非聚集索引本身中更为优化——但这非常有情境，通常Key Lookups效果很好。

    将聚簇索引添加到表中的唯一小缺点是，当根据索引的键插入或更新行时，索引管理自身的开销很小。通常情况下，聚集索引带来的读取性能收益远远超过写入开销。表上没有聚簇索引的情况很少见。一个例外是用例，其中表始终被完整读取，从不或很少更新或删除，仅插入或截断 - 例如，暂存类型的表。

    • 4

相关问题