在时间维度表中应该将索引放在哪里？

在阅读了该网站有关索引的问答后，我想到了一个问题。

如果使用的是时间维度表，而粒度级别较低则为日。索引应该放在哪里？

Randy Melder的问题是：“索引”在RDBMS上意味着什么？说过 ：

将索引视为“目录” ...即文件位置的指针的有序列表，又称偏移量

就时间维度而言，如果时间表存储了唯一年份的全天，则大多数数据研究可能针对特定的一天，特定的一周，特定的月份或特定的季度进行。

我的问题是：是否应该为所有这些字段设置索引？

Day被认为是唯一的，因此对于这一天，我完全理解索引的使用。但是一个星期id将发生7次，一个月id将发生30/31次，一个季度id将或多或少发生120次。

• 还应该为那些字段添加索引吗？
• 还会有用吗？

我问你，因为在同一问题上，大卫·斯皮利特（David Spillett）说：

当然，添加过多的索引可能是一个糟糕的优化，因为用于存储索引的额外空间（如果您的DB看到许多写操作，则还有用于维护索引的IO负载）可能比最优读取请求稍差一些，这是一个更糟糕的问题。 ，所以不要过度操作。

那么，对于时间维度情况，最好的考虑因素是什么？

您可能不会遇到写问题，因为我认为这将是一次（或每年一次）创建，然后再不涉及的问题。

但是，如果您按周进行搜索，则使用索引可能会成为一个障碍。问题是，如果使用了索引，它可能会先进行扫描，然后再分别从表中获取每个记录，而当您使用重新拉出大约5-20％的记录，通常进行全表扫描的速度会更快，然后删除不需要的记录。

我不知道任何主要的RDBMS在数据分布良好时都不会对此进行优化。如果分布不正确（例如，一列中的一个值出现在95％的时间中，但是还有其他可能的值），则您可能不得不在表格上计算直方图，并且在搜索时不使用占位符作为该值，以便查询优化器在生成执行计划时具有要搜索的值。

我可能不会索引星期几。我将检查数据库的文档，以了解索引读取与全表扫描的权衡是什么，以查看是否要对每月的某天或一年中的某天进行索引。如果有的话，我很可能会索引一年中的每天DOY（无论如何，这听起来像是您的唯一索引）

索引不必唯一就可以使用，因此答案取决于它。如果您的查询受益于索引的存在，那么它们可能是值得添加的。我不知道关于时间栏应该有任何特殊的指导原则。像对待其他任何列一样对待它们，并根据对查询的有用性对其进行索引。

一般规则是索引的选择性越强（选择性定义为列中唯一值的数量除以表中的行数），如果查询，引擎将更可能使用索引在where子句中使用该列。

如果要考虑为列建立索引，则在索引列的前后运行查询，然后查看执行计划，这将告诉您是否正在使用索引，如果使用索引，则索引有多大帮助。理想情况下，用于测试的查询是应用程序将使用的查询。

到目前为止，我的经验法则是在我处理开发数据库时，根本不将任何索引放入开发数据库中。随着生产数据库的变大，我使用数据库日志记录并EXPLAIN找出需要索引的内容，然后仅创建必要的索引。只要数据库使用率逐渐增加，并且保持索引计数较低，此方法就可以正常工作。

在分析数据库中的数据时，我通常需要添加其他索引来加快在生产中不常见的请求。我总是在生产数据库的副本上执行此操作，因此这些索引永远不会添加到生产本身。