一张桌子可以“太小”，无法通过索引获得任何收益吗？

Question

假设我有一张表永远不会超过10条记录。是否对其进行索引有任何有形的利益？会有负面结果吗？

20条记录怎么样？ 50？ 500？假设数据库具有现代化，强大的专用服务器硬件，那么表格在什么时候实际上会看到索引的实际好处。

Answer 1

像任何事情和所有SQL一样， IT DEPENDS 。

对于10记录表，您可能永远不会看到使用的索引。优化器会将表扫描和索引扫描之间的差异视为nil。

对于较大的表，它将依赖。没有“切断点”，它对每张桌子都有益。它取决于行宽，索引字段的选择性，索引的宽度，如果它是聚簇的还是非聚簇的等等。

我会说如果你开始遇到性能问题，看看索引是否有所作为。如果一个表超过1000行，我通常会将其编入索引，如果我将加入它，因为使用的空间和创建/维护索引的时间是微不足道的（假设你没有在一个小的表中删除/插入很多）

Answer 2

对于非常小的表，索引可能不会用于简单访问 - 表扫描的成本低于索引查找，然后是实际的数据检索/引用。

如果该表很可能用于针对大得多的表运行的子查询，那么无论如何都要对其进行索引。数百或数千次表扫描的成本很快就会使与该表相关的任何其他成本相形见绌。

我们手动展开对相关子查询中使用的一个这样的表（大约20行）的引用与更大的表。在一个客户端，此查询使用了42亿次读取，因为它正在对较大表中的每个链接行执行表扫描。展开该操作导致读数减少99％（之后约为38万），运行时间减少18小时。

编辑：创建特定于子查询的连接参考。

Answer 3

如果表格非常小​​，查询优化器可能会选择不使用索引。如果没有任何好处，您将承担维护费用。因此，在这种情况下，它对于任何收益来说都太小了。但这主要是没有实际意义，因为如果表格很小，那么维护费用就不会很大。

如果你的表位于may-help-might-not-grey区域，我的感觉就是：除非你有数据表明它会有所帮助（Profiler或类似的东西），否则不要对它进行索引。数据库服务器可用的内存 - 在大多数情况下，并非全部 - 相对于数据库本身的大小而增长，允许更多的数据库适合缓存。其他人当然不同意，并且有完全有效的论据。

• 约翰

Answer 4

我没有看到只有1行的表如何可能从索引中受益。所以，是的。

Answer 5

如果表是FK关系，那么即使它有3个值（如果它是由300万行的表引用），它也很重要。从技术上讲，FK方面只需要有独特的约束。但是如果它只是一个只有3个值的聚类PK，那么当它将扫描转换为索引搜索时，它会被引用数百万次，这将带来实实在在的好处。