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

• DML 在你的桌子上
• 指数的存在使得它的速度慢得让人无法忍受,而且
• 快一点更重要 DML公司

non-covering . 像这样的查询通常是聚集索引的好候选,但是覆盖索引也一样好。

• 数据多久添加一次到此表中?如果有 阅读/搜索比添加/更改更多(一些表的整个要点是将数据转储到其中以供报告),那么您就想疯狂地使用索引了。ID字段可能需要更多的聚集索引,但是可以有大量的多列索引(日期字段在后面,索引中前面列出的列可以很好地减少结果集)和覆盖索引(所有返回值都在索引中,因此速度非常快,就像你在搜索聚集索引一样)。

• 如果表经常被编辑/添加,或者存储空间有限,因此不能有成吨的索引,那么必须更加小心地使用索引。如果您的日期标准通常提供大量数据,并且您不经常在其他字段上搜索,那么您 为这个日期字段提供一个聚集索引,但是在这样做之前要考虑好几次。聚集索引位于一个简单的自动编号字段上,这对所有索引都是一种奖励。非覆盖索引使用聚集索引压缩到结果集的记录。除非 你的大部分搜索都在那个日期字段上。这是核选择。

• 如果您不能拥有大量的覆盖索引(表中的数据变化很大,空间有限,结果集很大且多种多样),和/或您确实需要另一列的聚集索引,并且典型的日期条件提供了范围广泛的记录,并且您必须搜索很多,那么您就遇到了问题。如果可以将数据转储到报表表中,请执行此操作。如果你做不到,那么你就必须小心地平衡所有这些竞争因素。也许对于前2-3个搜索,您可以尽可能地最小化结果集列,尽可能配置覆盖索引,而剩下的部分则使用简单的非聚集索引

你可以理解为什么优秀的db员工应该得到高薪。我知道很多因素,但我很羡慕人们能够快速、正确地平衡所有这些因素,而不必做很多分析。

所以我要加上索引 ,但我使用的是SQL Server,它在大多数情况下都会使用索引。然而,不同的数据库很多都不使用索引。

BETWEEN 查询,以避免表扫描。

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

如果您通常使用like子句和通配符作为第一个字符进行查询,则不会使用索引,因此创建索引是对资源的另一种浪费。