日志表复合索引选型：(CreatedTime, Status)还是(Status, CreatedTime)？

核心结论 #

你的直觉完全正确：(CreatedTime, Status)这个复合索引在你的查询场景下，Status字段对性能的增益极其有限。

为什么(CreatedTime, Status)的增益可以忽略 #

• CreatedTime唯一性极高，当你按时间范围过滤后，返回的数据集已经非常小。此时再通过Status筛选，直接遍历这个小数据集的开销，远小于维护这个复合索引带来的额外写入成本。
• 复合索引的存储结构是先按CreatedTime排序，再按Status排序。在时间范围过滤后的结果集中，Status是无规律分布的（同一时间点可能存在多种Status），数据库无法利用索引的有序性快速定位特定Status，只能遍历过滤后的记录做筛选，这和在内存中对结果集做过滤的性能差异极小。

关于(Status, CreatedTime)索引的实际表现 #

你提到的“按Status分册、每册按时间排序”的思路，对应数据库中的**(Status, CreatedTime)**复合索引，其利弊和数据库优化逻辑如下：

• 优势：当你需要单独统计或筛选某一个Status的时间范围数据时，这个索引效率极高。数据库可以直接定位到目标Status的索引分区，再快速扫描对应时间区间的记录，无需遍历其他Status的数据。
• 合并排序的开销：当你需要查询所有Status的时间范围数据并排序时，数据库会从每个Status的索引分区中取出符合条件的记录，然后执行合并排序。由于你的Status只有3-5种取值，现代数据库的查询优化器可以高效处理这种小规模的合并操作，不会成为性能瓶颈。

针对你的查询场景的最优方案 #

• 优先使用单字段索引CreatedTime：你的核心查询场景是检索特定时间范围的日志，这个索引能快速定位到目标时间区间的所有记录，后续的Status筛选或统计直接在这个小数据集上进行，性能完全足够。
• 若存在频繁的单Status+时间范围查询/统计，可额外创建**(Status, CreatedTime)**复合索引：这个索引能针对性优化这类场景，且由于Status取值少，索引的维护成本远低于(CreatedTime, Status)（后者因为CreatedTime唯一性高，索引条目数几乎等于表记录数，写入时的维护开销更大）。
• 避免同时维护多个低效索引：根据你的核心查询频率做取舍，没必要为了极小的性能增益维护冗余索引。

内容的提问来源于stack exchange，提问作者Luke Vo