什麼是表的最佳數據量？

Question

表中應該有多少數據，以便讀數最佳？假設我有3個字段varchar（25）。這是在MySQL中。

Answer 1

行數不應該影響。確保您的搜索字段正確編制索引。如果你只有3個varchar（25）字段，那麼你可能需要添加一個不是varchar的主鍵。

Answer 2

同意您應該確保您的數據正確編入索引。

除此之外，如果您擔心表格大小，您可以隨時實施某種類型的數據存檔策略，以便在後續行中使用。

不要太擔心，直到你看到問題出現，並且不會過早優化。

Answer 3

爲獲得最佳閱讀效果，您應該有一個索引。一個表格用於存放它被設計爲包含的行。隨着行數的增加，索引的價值發揮了作用，閱讀仍然很活躍。

Answer 4

這樣說我不知道​​如何回答這個問題。包含100,000條記錄的idexed表比沒有索引的1,000條錶快。

您有什麼要求？你有多少數據？一旦你知道這些問題的答案，你可以做出索引和/或分區的決定。

Answer 5

我會建議你考慮優化您的數據庫設計如下：

1. 考慮要與數據庫完成的任務。你會以很高的價格執行大量插入到單個表格嗎？或者你會使用數據執行報告和分析功能？
2. 確定數據庫的用途後，請定義需要存儲哪些數據以執行所需的任何功能。
3. 正常化，直到它傷害。如果您正在執行事務處理（數據庫最常用的功能），那麼您需要高度規範化的數據庫結構。如果您正在執行分析函數，那麼您將需要一個更爲非規範化的結構，而不必依賴連接來生成報告結果。
4. 通常情況下，如果你真的對結構進行規範化直到它受到傷害，那麼你需要將規範化返回一兩步，以使數據結構既規範化又實用。
5. 如果您未能使用密鑰，規範化數據庫通常毫無意義。確保每個表都有一個主鍵定義。不要使用代理鍵，只會導致你總是看到的東西。考慮任何給定表格中可能存在的自然鍵。一旦確定每個表都有正確的主鍵，則需要定義外鍵引用。建立明確的外鍵關係而不是依賴隱式定義將會提升性能，爲數據提供完整性，並自行記錄數據庫結構。
6. 查找表中存在的其他索引。你有一列或一組列，你會經常搜索像用戶名和密碼字段？索引可以位於單列或多列，因此可以考慮如何查詢數據並根據需要創建索引來查詢所要查詢的值。

Answer 6

這是一個非常鬆散的問題，所以非常寬鬆的答案:-)

一般來說，如果你做的基礎 - 合理正常化，一個明智的主鍵和運行的設施，工廠的查詢 - 那麼在今天的硬件上，你會在中小型數據庫上獲得大多數東西 - 即最大的表中有少於50,000條記錄的數據庫。

但是，一旦你超過了50k-100k行，這大致對應於rdbms可能受內存約束的點 - 那麼除非你有正確的訪問路徑設置（即索引），然後性能將開始脫落災難性的。這在數學意義上說 - 在這種情況下，表格尺寸加倍會導致性能下降一到兩個數量級，這並不罕見。

因此，很顯然，需要注意的關鍵表格大小會因行的大小，機器內存，活動和其他環境問題而有所不同，因此沒有單一答案，但最好注意性能不會隨着桌子尺寸而適度地降低並相應地計劃。

Answer 7

我不同意Cruachan關於「50k - 100k行....大致對應於rdbms可能受內存限制的點」。沒有兩個額外的數據，這個一攬子聲明只是誤導。行的大小和可用內存。我目前正在開發一個數據庫，以便在源代碼文件中查找最長的常見子序列（一種生物信息學）行，並在一個表中達到數百萬行，即使VARCHAR字段接近1000，在它變爲內存之前限制。因此，在適當的索引和足夠的RAM（一個或兩個）的情況下，就原始問題而言，最多有75個字節的行，沒有理由說建議的表無法保存數千萬條記錄。

Answer 8

適量的數據是應用程序的函數，而不是數據庫的函數。通過將表分成多個子表來解決MySQL問題的情況很少，如果這是您問題的意圖。

如果您在查詢速度慢的特定情況下，通過修改查詢或表設計來討論如何改善這種情況可能會更有用。