如果我有它很少的记录（比如，少于十）查找表，我应该打扰把索引其它表的外键，它是连接？ 对于这个问题，并查找表甚至需要在主键上的索引？
具体而言，有没有性能优势是远远超过维护索引的开销？ 如果没有，是否有任何好处比速度等？
注意：查找表的一个例子可能是订单状态，这里的元组是：
1 - Order Received
2 - In Process
3 - Shipped
4 - Paid
Answer 1:
在一个交易系统中，可能是把一个指标上这样的列（即低基数的参考列）作为查询优化器可能不会使用它没有显著的好处。 它也将产生在写入表中其他磁盘流量作为指标必须进行更新。 因此，对于事务数据库低基数FK的通常最好不要索引的列。 这尤其适用于高容量系统。
请注意，您可能仍然希望在FK参照完整性和一个小参考表中的FK查找可能会产生没有I / O的查找表几乎总是被缓存。
但是，你可能会发现你想在某种原因综合指数列 - 也许是为了创建一个最常用的查询覆盖索引。
上表是经常批量加载（如数据仓库）中的索引写入流量会比表负荷大得多，如果你有很多索引列。 您可能需要删除或禁用FKS和索引批量加载如果任何指标都存在。
在一个星型模式 ，你可以从索引低基数列，即使是在SQL Server的得到一些好处。 如果你正在做一个具有高度选择性查询（即一个在查询优化器决定返回的将是小的行集），那么它可以做它使用一种被称为索引交集的技术“星查询”计划。
一般来说，在一个星型模式的查询计划，应根据各地的事实表，或者用书签保存了事实表高度选择性过程的表扫描，然后返回一组较小的行。 索引交集是高效后者类型的查询的选择可以在事实表上做任何I / O之前解决。
位图索引对于支持它们的平台上低基数列，比如甲骨文成为真正的赢家，但SQL Server不。 即便如此，低基数指标仍然可以参与SQL Server上的星型查询计划。
Answer 2:
是的，总是有一个索引。
现代数据库管理系统（DBMS）的查询优化器将做出确定哪个是更快的：（1）实际上是从一个索引读取上的柱，（2）执行全表扫描。
表的大小（以行数）需要“足够大”为索引的使用要考虑的。
Answer 3:
是两者。 总指数作为一个经验法则 。
要点：
- 您也无法建立一个FK没有查找表的唯一索引
- 如果你想在什么查找表删除或更新？ 尤其是意外......
然而，他说，我们这样做并非总是如此。
我们有非常OLTP表（500万行每天+）与几个父表。 我们只在哪里，我们需要他们的FK列的索引。 我们假设在某些父表没有删除/密钥更新，所以我们减少所需的工作和磁盘空间的使用量。
我们使用SQL Server 2005和的动态管理视图来建立索引没有使用。 我们仍然有FK到位，虽然。
Answer 4:
我个人的意见是，你应该......这可能是小的，现在却总是期待你的表的规模越来越大。 一个好的数据库模式将与更多的记录轻松地成长。 外键几乎总是一个好主意。
Answer 5:
在SQL Server，主键是聚簇索引如果没有一个已（即聚集索引）。
文章来源: Should Lookup Table Foreign Keys Always be Indexed?
