查找时间比较：外键存在或不存在答案

【问题标题】：Comparison of lookup times: foreign key is or is not present查找时间比较：外键存在或不存在
【发布时间】：2012-09-05 19:02:27
【问题描述】：

一位同事最近向我描述了重新构建数据库的计划。新数据库将符合简单的star schema：父表将包含一个键和一些上下文信息，并且该键将用作其他表中的外键字段。外键字段可能多次出现在同一个子表中。

伪代码：

TABLE Parent
   INT key PRIMARY_KEY
   INT foo
   ...

TABLE Child1
   INT key FOREIGN_KEY REFERENCES Parent.key
   BLOB bar
   ...

TABLE Child2
   INT key FOREIGN_KEY REFERENCES Parent.key 
   VARCHAR tar
   ...

设计背后的动机是简化 Parent 和 Child<n> 之间的 JOIN，这在之前的架构中很复杂。

为了进一步加快 JOIN，我的同事希望尽量减少 OUTER JOIN 的使用。具体来说，她想通过使用 JOINS 并通过以特定方式维护子表中的数据来模拟 OUTER JOIN：填充所有子表，以便对于 Parent 中的每个 key，@987654327 中至少有一行@ 具有 key 值，即使该行以其他方式充满 nulls。这样，在key 上的Parent 和Child<n> 之间执行的任何JOIN 都会为Parent 中的每个key 返回至少一个结果，这更像是一个OUTER JOIN。

抛开以这种方式维护数据是否值得付出努力的问题不谈，假设所有key 字段都已正确索引并且大约一半的子行是@，这种方法是否比执行外部联接更高效987654336@退出？

问题似乎归结为“对索引中存在的值而不是不存在的值进行索引查找更快？”假设索引像 B 树或哈希一样运行，我的答案是“否”，但我知道的不够多，无法确定。

【问题讨论】：

不确定你有什么星型模式。一个典型的明星会有一个事实表（我猜是你的“父母”）和许多维度表（我猜是你的“孩子”）。事实将具有各种维度键。例如，销售事实表可能包含 product_id、time_id、store_id 等键。所以不确定我是否完全理解您的方法

标签： database performance oracle join

【解决方案1】：

就个人而言，我没有注意到外连接和内连接之间的主要性能差异。为什么你的同事认为他们比较慢？

添加额外的记录对性能有两个影响。原始数据变大，需要更多的页面来存储数据。这会对性能产生很大影响，尤其是当额外的页面（没有有用的数据）与更有用的结构（比如索引）竞争空间时。

第二个影响是对索引。它需要更大，这可能会导致更深的索引和更多的索引页面。这两种情况都会对性能产生影响。

还有另一个问题，与性能无关。编写查询的用户/开发人员需要充分了解这些空记录的存在。执行 COUNT(*) 或 COUNT() 并期望结果准确反映包含数据的记录数非常容易。如果不是这种情况，您可能会在以后导致编码问题。

【讨论】：

【解决方案2】：

我认为这种方法不会提高性能。

内连接通常比外连接快。这是因为内部连接的限制性更强，使优化器有更多机会在计划的早期减少结果集。

但是，如果您人为地添加数据，您的内部联接将不再受到更多限制。

【讨论】：