是否应始终将数据库表中的可搜索日期字段编入索引？

Question

如果我在某个日期类型的表格中有字段，并且我知道我将始终使用between，>或<之类的比较进行搜索，并且永远不会{{1可能有一个很好的理由不为它添加索引吗？

Answer 1

不在您要搜索的字段上添加索引的唯一原因是维护索引的成本超过了它的好处。

如果出现以下情况，可能会发生：

• 你的桌子上有一个非常艰难的DML
• 索引的存在使它变得无法忍受地慢，
• 快速DML比快速查询更重要。

如果不是这样，那么只需创建索引即可。如果认为不需要，优化器就不会使用它。

Answer 2

还有很多不好的理由。

但是，如果索引是非聚簇且non-covering，则搜索列上的索引可能不够。像这样的查询通常是聚簇索引的良好候选者，但覆盖索引也同样好。

Answer 3

这是一个很好的例子，说明为什么这个艺术与科学一样多。一些注意事项：

• 数据添加到此表的频率是多少？如果远更多的读取/搜索比添加/更改（某些表的整点以将数据转储到报告中），那么您希望对索引感到疯狂。 ID字段可能需要更多聚集索引，但是您可以拥有大量多列索引（日期字段稍后出现，索引中前面列出的列可以很好地减少结果集），并且索引（所有返回的值都在索引中，所以它非常快，就像你在搜索聚簇索引一样开始）。

• 如果经常编辑/添加表，或者您的存储空间有限，因此无法拥有大量索引，那么您必须更加小心索引。如果您的日期条件通常会提供大量数据，并且您不经常在其他字段上搜索，那么您可以将聚集索引提供给此日期字段，但在您执行此操作之前请多次考虑那。您在一个简单的自动编号字段上的聚集索引是所有索引的奖励。未覆盖的索引使用聚簇索引压缩到结果集的记录。不要将聚集索引移动到日期字段，除非您搜索的浩大大多数都在该日期字段上。这是核选择。

• 如果你不能拥有很多覆盖的索引（表上的数据变化很大，空间有限，结果集很大且变化多了），和/或你真的需要聚集索引列，典型的日期标准提供了广泛的记录，你必须搜索很多，你有问题。如果可以将数据转储到报告表，请执行此操作。如果你不能，那么你必须仔细平衡所有这些竞争因素。也许对于前2-3个搜索，您可以尽可能地配置覆盖索引来最小化结果集列，并使用简单的非聚簇索引使其余部分到期

你可以看到为什么好的数据库人应该得到报酬。我知道很多因素，但我羡慕人们可以快速准确地平衡所有这些事情，而无需进行大量的分析。

Answer 4

如果您想每次扫描整个表格，请不要将其编入索引。我希望数据库尝试进行范围扫描，所以我要添加索引，但我使用SQL Server，它会在大多数情况下使用索引。但是，不同的数据库很多都没有使用索引。

Answer 5

根据数据的不同，我会更进一步，如果您要进行BETWEEN查询，建议它可以是聚簇索引，以避免表扫描。

Answer 6

虽然索引有助于查询表，但它也会减慢插入，更新和删除的速度。如果表中的更改比查询多得多，则索引会影响整体性能。

Answer 7

如果表很小，它可能永远不会使用索引，因此添加它们可能只是浪费资源。

有一些数据类型（如SQL Server中的图像）和数据分布，其中索引不太可能被使用或无法使用。例如，在SQL Server中，索引位字段是没有意义的，因为索引的数据没有足够的可变性来做任何好事。

如果您通常使用like子句和通配符作为第一个字符进行查询，则不会使用任何索引，因此创建一个索引会浪费其他资源。