查找表外键是否应始终被索引？

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上的星型查询计划.