MySQL：建議的行數

Question

考慮一個帶有7列的索引MySQL表，不斷查詢和寫入。通過將數據分解到其他表中來改進性能之前，該表應該被允許包含多少行？

Answer 1

您是否通過對數據進行分區來獲得性能增益取決於數據以及您將在其上運行的查詢。您可以將數百萬行存儲在表中，並且具有良好的索引和精心設計的查詢，它仍然會超快速。如果你已經確信你的索引和查詢是儘可能好的，那麼只考慮分區，因爲它可能比它的價值更麻煩。

Answer 2

雖然事實上你可以指出性能成爲問題的表的大小，但我不認爲你可以預測它，當然不是從這樣的網站上給出的信息！

有些問題你可能會有效地問自己：

• 是目前的表現可以接受？
• 績效如何衡量 - 是否有 有一個指標？
• 我們如何識別 不可接受的性能？
• 難道我們 以任何方式衡量表現 可能允許我們預測 問題？
• 是否我們所有的查詢使用 有效索引？
• 我們模擬了系統的極限負載和體積嗎？

Answer 3

使用MyISAM引擎，除非更改默認值，否則將在表大小上遇到2GB硬限制。

Answer 4

沒有什麼神奇的數字，但還有影響性能尤其是幾件事情：

• 指數基數：甭管索引有2個或3個值（像一個ENUM）一行。在大表上，查詢優化器將忽略這些。
• 寫入和索引之間存在折衷。您擁有的索引越多，寫入的時間就越長。不要只索引每一列。分析您的查詢並查看哪些列需要爲您的應用建立索引。
• 磁盤IO和內存起着重要作用。如果你可以將整個表格放入內存中，則可以將磁盤IO從等式中刪除（無論如何，一旦表格被緩存）。我的猜測是，當你的表太大而無法在內存中緩衝時，你會看到性能發生巨大變化。
• 考慮根據使用對服務器進行分區。如果您的交易系統正在讀取/寫入單個行，您可能需要花費一些時間將數據複製到只讀服務器以進行彙總報告。

正如您可能知道的那樣，表格性能會根據數據大小進行更改。密切關注你的表格/查詢。你會知道什麼時候需要改變。

Answer 5

如果您認爲不需要，請不要應用優化。理想情況下，這應該通過測試來確定（如其他人所暗示的）。

水平或垂直分區可以提高性能，但也會使應用程序變得複雜。除非你確定你需要它，否則不要這樣做，這一定會有所幫助。

2G數據MyISAM文件大小隻是一個默認值，可以在創建表時更改（或稍後由ALTER更改，但需要重建表）。它不適用於其他引擎（例如InnoDB）。

Answer 6

其實這是一個很好的性能問題。你讀過Jay Pipes嗎？沒有特定的行數，但是讀取有特定的頁面大小，並且垂直分區可能有很好的理由。

看看他的功夫介紹，並通​​過他的職位看看。我相信你會發現他寫了一些有用的建議。

Answer 7

你在使用MyISAM嗎？你打算存儲超過幾千兆字節嗎？注意MAX_ROWS和AVG_ROW_LENGTH。

Jeremy Zawodny有關於如何解決這個問題的excellent write-up。

Answer 8

MySQL 5有partitioning內置，非常好。最好的是你可以定義你的表應該如何分割。例如，如果您主要基於用戶標識進行查詢，則可以基於用戶標識對您的表進行分區，或者如果您按日期查詢，則按日期進行分類。有什麼好處的是，MySQL會準確知道要通過哪個分區表來查找你的值。缺點是如果你在一個沒有定義你的分區的領域搜索它將掃描每個表，這可能會降低性能。