重新思考索引:数据库索引现代化的路径

索引是数据库性能的基础，但它们常常被视为“设置后就不再理会”的结构。随着数据环境的演变，包括混合云部署、实时分析和机器学习工作负载的出现，我们的索引策略也必须随之调整。

事实上，随着技术进步和数据量激增，十年前或二十年前行之有效的索引策略如今可能已不再是最优的。造成这一现象的原因多种多样，包括数据库管理系统为提升索引性能而进行的改进(如新增索引类型和选项)，以及应用程序编写和维护方式的变革。让我们探讨这些问题，并揭示数据库应用中索引现代化的迫切需求。

我们继承的索引

坦白说：我们环境中的许多索引并不是经过精心设计的，它们是被继承下来的，或是为了快速解决性能问题而添加的，或是为了满足临时访问路径而创建的。随着应用程序的变更和数据模式的演变，这些遗留索引可能变得无关紧要、冗余，甚至有害。

现代化始于意识觉醒。问自己：这个索引为何存在?如果你无法自信地回答，是时候深入挖掘了。查询负载会变化。十年前的优化访问路径可能已不再适用。

冗余和重叠索引

消除冗余索引是现代化的一大机遇。你的数据库管理系统(DBMS)平台允许你定义多个索引，这些索引可能重叠或以不同方式覆盖同一列，但这仅仅因为你可以这样做，并不意味着你应该这样做。

考虑以下场景：

• 一个索引在 (LASTNAME, FIRSTNAME) 上

• 另一个在 (LASTNAME) 上

第二个索引在功能上是冗余的。第一个索引涵盖了第二个索引可以支持的所有查询——以及更多。保留两个索引会不必要地增加每次插入、更新和删除操作的成本。

也许第二个索引是主键的唯一索引，而第二个索引是为了提升性能。在这种情况下，你不能简单地删除第二个索引。相反，如果你的数据库管理系统支持索引包含列，你可以将FIRSTNAME列包含在第二个唯一索引中，而无需将其作为实际索引键的一部分。这样，通过使用可能更新的功能(包含)，你可以消除冗余索引并提升性能。

聚簇和压缩考虑

现代化不仅仅是删除。它还涉及更智能地重建。聚簇索引影响物理数据布局，而不良的聚簇可能会降低性能。作为现代化的一部分，审查聚簇索引是否仍与主要访问路径匹配。

此外，新的索引压缩技术(在某些数据库管理系统如Db2中可用)可以节省空间并减少I/O。如果您仍然只使用数据页压缩而未探索索引页压缩，您将错过潜在的CPU和存储节省——尤其是在高基数索引中，其中包含大量重复值。

采用现代索引类型

每个现代数据库管理系统(DBMS)都会在其产品的新版本和新发布中提供新的和改进的功能。作为这些发布的一部分，许多改进已经实现，提供了更先进的索引类型和改进的索引维护功能。基于表达式的列上的索引、对更大索引键的支持以及更好的内联维护选项意味着您可以设计更智能的索引，更好地服务于分析查询和事务性工作负载。

数据库管理员(DBA)的角色

索引现代化并非一次性任务，而应纳入持续的索引生命周期管理策略。当今的DBA必须：

• 自动化索引分析与优化

• 与开发人员协作以理解查询需求

• 将索引使用跟踪集成到持续集成/持续交付(CI/CD)管道中

• 监控新应用程序对现有访问路径的影响

要有效分析和现代化索引策略，需要捕获并分析现有SQL以构建更有效的索引模型。为此，索引分析工具可帮助减少手动步骤，并构建必要的基础设施和脚本以有效审查运行中的SQL语句。

您应该捕获一段时间内的所有SQL使用情况，该时间段需足够长以涵盖您运行的最重要应用程序和查询的横截面。同时，您需要将这些信息与数据库管理系统(DBMS)系统目录和查询计划详细信息进行集成。利用这些信息，您可以进行分析以确定现有索引的类型，以及可能需要创建的索引。

您需要考虑的因素包括未使用的索引、统计信息缺失或过时的索引、具有重叠键列的索引、重复索引、索引过多的表、外键索引不完整的表、没有聚集索引的表，以及完全没有索引的表。

在审查和分析系统后，您可以决定保留哪些索引以及创建哪些索引。务必为应用程序性能的“前后对比”建立基线。然后，您可以通过访问路径、CPU 节省和其他“成本因素”来确定新索引对应用程序的影响，以及哪些应用程序从新索引中获益最多。

索引并非被动结构，它们是主动的性能工具。但就像任何工具一样，如果不维护和现代化，它们会随着时间的推移而“生锈”。

最终思考

索引现代化并非盲目淘汰旧有索引，而是通过数据驱动的分析确保索引与当前及未来的工作负载需求保持一致。在当今动态环境中，臃肿且过时的索引策略可能成为性能和可扩展性的隐形杀手。

随着数据量增长和业务需求增加，采取战略性索引现代化方法将成为提高数据库环境的关键差异化因素。

作者：Craig S. Mullins