主页 / coding / 问题 / 79526871
Accepted
Luke Vo
Asked: 2025-03-22 10:44:03 +0800 CST

数据库日志表上的复合索引：（状态，创建时间）还是（创建时间，状态）？

  • 772

(CreatedTime, Status)我通常为我的表使用复合键Log，但我正在重新考虑这种设计。由于CreatedTime通常非常独特，并且Status只有 3-5 个可能的值，因此似乎Status在之后的进一步过滤中不会增加太多CreatedTime。

我的大多数查询都涉及检索特定时间范围内的日志，可选择按 进行筛选或计数Status。从概念上讲，如果我使用按时间排序的物理日志簿，则识别具有特定Status（例如“成功”）的条目会很麻烦。另一方面，为每个 都设置单独的日志簿Status，并按时间排序，可以使搜索更有效率——尽管合并和重新排序所有Status值的结果可能会使事情变得复杂。数据库是否针对此类场景进行了优化？

我已经就此问题询问了三个不同的 AI，但他们的答案含糊不清且相互矛盾（甚至同一个 AI 只需提出略微不同的问题，就会给出不同的答案），而且我在 Google 和 SO 上找不到太多相关信息。有人能确认我的直觉是否正确吗？

sql

2 个回答

  1. Best Answer

    您的索引应基于您通常查询数据的方式。由于您通常查询给定日期范围的日志，因此索引CreatedTime将是最有效的。我怀疑辅助索引Status不会产生重大差异，除非您查询大量日志而没有您的日期范围，并且只有少数日志符合您想要的状态。此外，由于您很可能不会同时拥有多个不同状态的日志，因此子索引没有帮助，因为它无论如何都必须扫描给定时间范围内的所有索引记录。

    与想要记录一种状态相比，索引速度Status, CreatedTime并不会明显更快CreatedDate, Status，而且如果强制引擎扫描多种状态并合并结果，性能会降低。

    次要的是如何添加数据。由于您几乎肯定会按顺序添加日志，因此按 建立索引的Status, CreatedTime效率会较低，因为您会经常在中间插入记录，这使得添加记录变得更加困难。按 建立索引CreatedTime意味着您几乎总是会在表的末尾添加记录，除非出现批量导入旧日志等异常活动。

    • 3

  2. 我推荐两个索引：

    • CreatedTime

    • Status, CreatedTime where Status != 'OK' - 部分索引

    您可能想要查询某个时间段内的所有日志，以及Status=Error某个时间段内的所有条目。这两个索引将帮助您完成这两个任务。由于绝大多数日志条目可能都有OK状态（或等效状态），因此第二个索引将小得多。

    通常，将日志存储在数据库中的成本效率不高。它可能会导致备份和恢复时间过长、存储使用量突然增加导致存储空间不足错误、在清理时出现意外的 IO 使用量峰值以及其他潜在问题。

    • 1

相关问题