众所周知，明智地使用索引可以帮助 SELECT 查询显着更快地执行。这可能会令某些数据库管理员（DBA）尝试通过向可能包含在查询中的每一列添加索引来尽可能提高性能。在表中添加索引的缺点是它们会影响写入的性能。此外，不正确创建的索引甚至会对 SELECT 查询产生不利影响！任何由于索引过多、不正确或缺失而导致性能下降的表配置都被认为是不良索引。在今天的文章中，我们将了解不良索引的后果，并介绍如何选择将哪些列作为聚集索引的一部分。
不良索引的影响
一个不良索引可以是在一列上创建的索引不提供更简单数据操作，也可以是在多列上创建的索引不能加快查询速度，而是减慢查询速度。
如果未正确创建索引，数据库必须遍历更多记录才能检索查询请求的数据。因此，它会使用更多的硬件资源（处理器、内存、磁盘和网络）并使获取数据的时间変得更长。
在某些情况下，没有聚集索引的表也可以被认为是一种不良的索引做法。在大多数情况下，在堆表（即没有聚集索引的表）上执行 SELECT 语句、插入、更新和删除记录比在聚集表上慢。
为聚集索引选择列
在关系数据库中创建带有主键（PK）的表时，会自动在主键列上创建唯一的聚集索引。尽管在大多数情况下此默认操作是完全可以接受的，但这可能不是数据的最佳索引。
组成聚集索引的列应形成唯一、标识、主键或任何组合，使其中每个新条目的值都会增加。由于聚集索引根据值对记录进行排序，因此使用已按升序排列的列（例如标识列）是一个不错的选择。
值经常变化的列不应用于聚集索引。原因是用于聚集索引的列的每次更改都需要对记录进行重新排序。通过使用更新频率较低或理想情况下根本不更新的列，可以轻松避免这种重新排序。
同样，存储大数据的列，例如 BLOB 列（text、nvarchar(max)、image 等）和 GUID 列对于聚集索引并不理想。这是因为对大值进行排序非常低效，并且在 GUID 和 image 列的情况下，排序没有多大意义。
最后，聚集索引不应建立在已在唯一索引中使用的列上。
总结
在今天的文章中，我们了解了不良索引的后果，以及如何选择将哪些列作为聚集索引的一部分。在即将发表的文章中，我们将介绍为某些操作提供更好性能的相同索引如何增加其他操作的开销。
Rob Gravelle 居住在加拿大渥太华，是一名有 20 多年经验的 IT 专家。过往，Rob 曾为与情报有关的组织（如加拿大边境服务局和各种商业组织）构建系统。在业余时间，Rob 是一名出色的吉他演奏家，他拥有多张 CD 和数字发行版。
