MySQL性能;大數據表還是多個數據表？

我有一個會員數據庫，我正在尋找重建。每個成員在主成員表中有一行。從那裏我將使用JOIN來引用來自其他表格的信息。我的問題是，以下的性能會更好：MySQL性能;大數據表還是多個數據表？

1數據表，指定數據類型，然後指定數據。示例：

data_id | member_id | data_type |數據
1 | 1 |電子郵件| [email protected]
2 | 1 |電話| 1234567890
3 | 2 |電子郵件| [email protected]

或者

它會更好，使所有的電子郵件地址的表，然後將所有的電話號碼錶等，然後使用具有多個select語句加入

請記住，此數據庫將以超過75000行的成員表開始，並且實際上將包括電話，電子郵件，傳真，名和姓，公司名稱，地址城市狀態zip（意味着每個成員將具有每個人中至少有1個，但可以有多個（通常每個成員1-3個），因此超過75000個電話號碼，電子郵件地址等）

所以基本上，加入的超過75萬行1種表或加入的7-10表超過75000行

編輯：此數據庫的性能變得當我們插入銷售問題需要將數據與數據庫中的現有數據進行匹配，因此需要獲取10k行銷售和聯繫人數據的CSV文件並查詢數據庫以嘗試查找CSV中哪些銷售行的哪些成員屬性？噢，這是在網絡服務器上完成的，而不是本地機器（不是我的選擇）

來源

2012-04-11 Spenser David Fishel

下面的答案可能是有趣的。 http://stackoverflow.com/questions/4419499/mysql-nosql-help-me-to-choose-the-right-one-on-a/4421601#4421601 – 2012-04-12 12:44:42

構建這個結構的一個顯而易見的方法是爲每個需要跟蹤的數據項（電子郵件，電話等）提供一列表。如果一個特定的數據項每個成員可以出現多次，那麼它取決於該項與成員之間關係的確切性質：如果該項自然發生可變次數，則將它們放入帶有成員表的外鍵的單獨表。但是，如果數據項可以在一組有限的固定角色（比如家庭電話號碼和手機號碼）中出現多次，那麼在成員表中爲每個角色創建一個不同的列是更有意義的。

如果你遇到這個設計的性能問題（我個人認爲75000不是那麼多 - 如果你有索引來正確支持你的查詢，它應該不會產生問題），那麼你可以對數據進行分區。 Mysql支持本地分區（http://dev.mysql.com/doc/refman/5.1/en/partitioning.html），它基本上將行集合分佈在單獨的物理隔間（分區）上，同時保持一個邏輯隔間（表）。這裏顯而易見的好處是，您可以繼續查詢邏輯表，而不需要手動將數據從多個地方聚集起來。

如果你仍然不認爲這是一個選項，你可以考慮垂直分區：也就是說，將一組列或甚至單列放在他們自己的表中。如果有一些查詢總是需要一組特定的列，而其他查詢傾向於使用另一組列，那麼這很有意義。只有這樣纔有意義應用這種垂直分區，因爲聯接本身會降低性能。（如果你真的遇到了數十億分鐘，那麼你可以考慮使用分片 - 也就是說，使用單獨的數據庫服務器來保留行的分區。這是有道理的，只要你能夠快速限制分片的數量需要查詢查找特定成員行或如果你能有效地查詢並行所有碎片。個人如果不是在我看來，沒有你會需要這個。）

我會強烈反對使得單「數據「表。這本質上將分散每一個自然會連續成列的東西。這需要大量的連接，並且複雜化寫入否則將是非常簡單的查詢。不僅如此，它也使得幾乎不可能爲您的數據創建適當，有效的索引。最重要的是，它很難將約束應用於數據（例如根據數據類型強制執行數據類型和數據項的長度）。

有一些角落的情況下，這樣的設計可能是有道理的，但提高性能不是其中之一。（請參閱：實體屬性值反模式http://karwin.blogspot.com/2009/05/eav-fail.html）

來源

2012-04-12 00:00:22

不幸的是把所有的日期放在成員表中不是一個選項是每個成員至少有一種數據類型，但可以想象它們的數量是無限的（大多數只會有1-3個，但我必須留出更多的可能性）。所以有一個查詢，加入一個電子郵件地址表和一個電話號碼錶和一個地址表等，然後只是一個數據表的單一連接，說：「從表中選擇數據，其中data_type =電子郵件或數據類型=手機等？ – 2012-04-12 00:42:40

你現在擁有75000名會員，你是否有多少數字具有哪些屬性（如電子郵件，傳真，電話等），以及該屬性的多少個實例（如果是多個電子郵件等）？可能很有吸引力說明理論上「可以想象」的東西，但這通常不是系統如何構建的，如果一個成員真的有100個電子郵件地址，你怎麼知道使用哪一個？或者你會使用它們全部嗎？ – 2012-04-12 10:57:05

當我第一次開始這項工作時，我只提出了相同的觀點，只是爲了學習這種合理的邏輯在這裏是徒勞無益的。問題是，更高級別的人認爲他們想要每個成員有無限量的屬性以防萬一。他們還喜歡添加屬性並隨時減去它們（所以有一天我們會收集電話號碼，第二天我們會這樣做，第二天我們收集企業的電話號碼而不是個人等）。是的，我的公司實際上會使用全部100個電子郵件地址（我們允許公司加入，我們將爲他們的員工獲得多個聯繫人） – 2012-04-12 13:51:07

對於數據庫，您應該研究scaling out vs scaling up。除了上述研究之外，如果您不期待大量數據，我會建議您在我們的案例中使用一張表。如果是，則在數據庫設計中查找dimensions。

來源

2012-04-11 23:50:46 kasavbere

75k對於數據庫來說確實不算什麼。你甚至可能沒有注意到有那麼多索引的好處（索引:)）。要點是，儘管你應該知道「向外擴展」的系統，但大多數DB包括MySQL，都可以通過分區來解決這個問題，從而允許你的數據訪問代碼仍然是真正的聲明性的，而不是編程的，尋址/查詢。重要的是要注意分片與分區，但老實說，當你開始超過記錄接近9+數字而不是5+的記錄時，會話就很重要。

來源

2012-04-12 00:22:13 Xailor

既不使用雖然第一個選項的變種是正確的方法。創建一個'查找'表，將存儲數據類型的值（郵件，電話等）。然後在'data'表中使用查找表中的id。這樣你實際上有3張桌子，而不是兩張桌子。其最佳實踐經典多對多關係如下：

來源

2013-06-03 01:51:05

MySQL性能;大數據表還是多個數據表？

回答

相關問題