當我們創建一個涉及一對多關係的數據庫設計時，隨着關係數據增長，存在潛在的性能損失風險。一對多關係設計性能
例如，讓我們從簡單的1到多關係涉及兩個表。
[User] 1 ----- m [Friends]
用戶可以有很多朋友。一個常見的設計是兩個表，其中一個包含所有用戶，另一個包含該用戶的所有朋友，其中用戶標識爲Friends中的外鍵。
但從技術上講，隨着用戶數量的增長，以及隨後的朋友數量的增長，將會有性能影響檢索用戶朋友列表。
有沒有解決這類問題的設計模式，還是現階段我們不得不依靠計算能力來維持性能呢？
但從技術上講，隨着用戶數量的增長，以及隨後朋友數量的增長，那麼將會有 的性能影響檢索用戶朋友列表。
是的。所以什麼？
使用指數。購買硬件。在確切的這個順序（看到多個重疊的服務器，因爲程序員從來沒有讀過http://use-the-index-luke.com/）。
你的問題是一個非問題，因爲殘酷地說，當你有更多的數據時，沒有辦法讀取更多的數據。這就是爲什麼某些數據庫每月需要超過5美元的廉價低端虛擬機的原因，並且目前在數據庫服務器中用於緩存的內存不會超過TB。
基本上你說「我開一家商店，我保留庫存，現在當我保留更多的庫存，我需要更多的空間，並且我不能在breackfast之前獨自處理工作，我該如何解決這個問題」答案是 - 獲得更多空間並僱用人力資源。在sql中的答案是 - 獲取更大的服務器。
這是除非你做了一些不聰明的事情，比如不在那裏放置適當的指數，那就是它。
虛擬機中具有6個內核和48GB內存的低端服務器（8核，每個4核，每個大約5年的雙Opteron）是我用於客戶聚合行數以億計條目在選擇的結果中（超過100億行數增長的表），是的，我們小心翼翼地佈置了光盤子系統（NEED IO），RAM有點短，有時最大限度地超出CPU。
但是我無能爲力。
隨着更多的數據，你需要更強大的硬件。
有關指標，執行在LOG（n）上大致取決於字（取決於很多因素） - 因此它不會線性滑動。如果你跳過索引，它是線性的 - 2倍長表，2倍長查詢和生活在痛苦中。因此，要勝任（至少在基線形式下的索引是非常基本的），然後在這個問題上拋出硬件。
沒有其他解決方案。
您可以使用索引功能，同時根據朋友表中的用戶選擇檢索朋友列表。
在您認爲性能會很差之前測試您的查詢。
在您的測試環境中生成測試數據，運行查詢，檢查結果，調整查詢，調整索引，檢查天氣或不改善性能，重複直至滿意。
正如我懷疑，thabks – kyndigs