SELECT 继承性能：LEFT OUTER JOIN vs "super-table" TYPE COLUMN答案

【问题标题】：SELECT inheritance performance: LEFT OUTER JOIN vs "super-table" TYPE COLUMNSELECT 继承性能：LEFT OUTER JOIN vs "super-table" TYPE COLUMN
【发布时间】：2014-08-02 03:11:29
【问题描述】：

我有继承的 SQL 表：

history (id, date, ip user_id)：“超级表”。
history_connection (id,user_agent)：映射用户的帐户连接。
history_email（id，email）：映射用户的电子邮件修改。

目标是在我的数据库中登录有关用户的不同类型的历史记录。 history_connection 和 history_email 的“id”列是一个主键和一个指向 history 表 id 的外键。

现在想象一下，在请求中，我不需要访问“子表”列，但我需要知道它是哪种类型的历史记录。马上，我想到了 LEFT OUTER JOIN：

SELECT h.id,h.date,h.ip,h.user_id,hc.id,he.id
FROM history h
LEFT OUTER JOIN history_connection hc
ON h.id=hc.id
LEFT OUTER JOIN history_email he
ON h.id=he.id

如果 hc.id 不为空，我可以推断历史的类型：在这种情况下，连接历史。问题是我认为它在性能方面不是很有效，因为如果我在“超类”history中添加一个“类型”列，我可以将这样的查询简化为：

SELECT id,date,ip,user_id,type
FROM history

我的问题是，您认为出于性能原因我需要添加类型列吗？

【问题讨论】：

你想LEFT OUTER JOIN但使用INNER JOIN？

标签： mysql database join left-join

【解决方案1】：

显然，只查看一个表的查询通常比进行连接的查询要快。但是，如果您的查询是这样的：

SELECT h.id, h.date, h.ip, h.user_id, hc.id, he.id
FROM history h LEFT JOIN
     history_connection hc
     ON h.id = hc.id LEFT JOIN
     history_email he
     ON h.id = he.id;

那么性能应该是相当不错的，在两个假设下：

您有适当的索引（history_connection(id) 和 history_email(id)）。
这些表不是太大（也就是说，它们适合内存）。

相比之下，正如您所描述的那样，维护type 列会产生额外的开销。您可以考虑将所有额外的列放在history 中。存储 NULL 值的开销很小。

【讨论】：