sql性能 - 從多個表中提取時的查詢設計

Question

好的，前提。三個表，爲這項工作很簡單：

table first: 
id, name 

table second: 
id, firstId, secondName 

table third 
id, thirdName, secondId 

我想在第三的是在第二個有一個關係到了一定的「第一」行ID一個ForeignKey到行所有行。

典型的SQL：

select t.id, s.id as secondId, t.thirdName, s.secondName from third t 
inner join second s on t.secondId=s.id where s.firstId = X 

因此，這裏是我的問題：

難道是更快的性能明智的，有在第三列，而不是直接的外鍵先？

即

table third: 
id, secondId, firstId, name 

所以，我反而可能使查詢：

select t.id, s.id as secondId, t.thirdName, s.secondName from third t 
inner join second s on t.secondId=s.id where t.firstId = X 

有沒有少加入，因爲我需要從「第二」的數據太多，但我會做的從第三位而不是第二位查找「firstId」。

只是好奇，如果任何人有任何輸入:)

Answer 1

假設第二種方式是更快，如果你重新寫你的第一個查詢爲：

select t.id, s.id as secondId, t.thirdName, s.secondName from second s 
inner join third t on t.id=s.id where s.firstId = X 

注意second的交換和展示位置third。有了這個，您將看到與第二個示例完全相同的性能，但third表格將更小，因爲它沒有額外的冗餘字段。

要指出的不具有本領域的好處，它更容易指出什麼增加額外的冗餘字段會做性能：

• 佔用更多的磁盤空間
• 減慢任何表掃描，因爲行現在將稍微不再
• 更新性能也將稍微慢
• 等等...

雖然理論上，它這個整體聽起來非常多像一個不成熟的優化，你只能做這個IF現有查詢慢（甚至做的是我上面重寫時），在該點通過改善索引，你會得到更好的回報。

Answer 2

找出來的最可靠的方法就是試試看。

但是，鑑於您需要連接到第二張表，我實際上預計它會慢一點，因爲您必須首先從表third中獲取所有記錄，然後將它們中的每一個鏈接到在second相應的記錄，而不是先取出second記錄，然後鏈接到third記錄 - 所以你會在第一個場景檢索2 * M * N個記錄，並且只（M + 1）* N的第二記錄。

當然，如果您不需要鏈接到second表，如果只訪問third表，查詢運行速度會快得多。

Answer 3

你提出的設計是不正確的。沒有什麼可以保證third.firstId匹配父行的second.firstId。

正確性比性能更重要！

---

這就是說，你可能可以使用識別的關係，自然鍵（相對於非識別關係和代理鍵）：

這是適當的，如果thirdName不不必須是唯一的自身，而只是從second表中的父行的背景下，和secondName確實ñ ot需要獨立於其自身，但僅限於first表的父行的上下文中。

在這種情況下，你能避免加入完全，仍然可以得到firstId，secondName和thirdName：

SELECT * 
FROM third 
WHERE firstId = X 

即使有其他領域，上面沒有顯示，你需要從second閱讀，在JOIN仍然會更快，因爲InnoDB clusters的數據，你更自然地遵循這個聚類。通過避免使用代理鍵，您可以避免使用昂貴的二級索引（請參閱this article中的「集羣的缺點」）。

你付出的代價是在每個連續的子表的增長逐步地「胖」。無論這是一個值得付出的代價，只有您可以通過對代表性數據量進行測量來確定。