Question

如果我的查找表中包含很少的记录（比如少于10个），我是否应该在其附加的另一个表的外键上放一个索引？就此而言，查找表是否甚至需要主键上的索引？

具体而言，是否有任何性能优势超过维护索引的开销？如果没有，除了速度有什么好处吗？

注意：查找表的示例可能是Order Status，其中元组是：

1 - Order Received
2 - In Process
3 - Shipped
4 - Paid

Answer 1

是的，总是有一个索引。

现代数据库管理系统（DBMS）的查询优化器将确定哪个更快：（1）实际读取列上的索引，（2）执行全表扫描。

表大小（行数）需要“足够大”才能使用要考虑的索引。

Answer 2

在事务系统上，将索引放在这样的列（即低基数参考列）上可能没有明显的好处，因为查询优化器可能不会使用它。由于必须更新索引，它还会在写入表时生成额外的磁盘流量。因此，对于事务数据库中的低基数FK，通常最好不要对列进行索引。这尤其适用于大容量系统。

请注意，您仍可能希望FK具有参照完整性，并且小型参考表上的FK查找可能不会生成I / O，因为查找表几乎总是被缓存。

但是，您可能会发现由于某种原因要将列包含在复合索引中 - 可能是为常用查询创建覆盖索引。

在经常批量加载的表（例如数据仓库）上，如果您有许多索引列，则索引写入流量将远远大于表加载的流量。如果存在任何索引，您可能需要删除或禁用批量加载的FK和索引。

在 Star Schema 上，即使在SQL Server上，您也可以从索引低基数列中获得一些好处。如果您正在进行高度选择性查询（即查询优化器决定返回的行集将很小），那么它可以执行“星形查询”计划，其中它使用称为索引交集的技术。

通常，星型模式的查询计划应该基于事实表的表扫描或者为事实表添加书签然后返回较小行集的高度选择性过程。索引交集对于后一种类型的查询是有效的，因为可以在对事实表执行任何I / O之前解析选择。

对于支持它们的Oracle等平台上的低基数列，位图索引是真正的胜利，但SQL Server却没有。即便如此，低基数索引仍然可以参与SQL Server上的星型查询计划。

Answer 3

两者都是。始终将索引作为经验法则。

点数：

然而，说，我们并不总是。

我们有几个父表的OLTP表（每天500万行+）。我们只对需要它们的FK列进行索引。我们假设某些父表没有删除/密钥更新，因此我们减少了所需的工作量和使用的磁盘空间。

我们使用SQL Server 2005 dmvs来确定未使用索引。我们仍然有FK。

Answer 4

我个人认为你应该......它现在可能很小但总是预计你的桌子会变大。一个好的数据库模式将随着更多记录轻松增长。外键几乎总是一个好主意。

Answer 5

在sql server中，主键是聚簇索引（如果没有聚簇索引）（聚簇索引）。