數據庫中有多少行太多了？

Question

我有一個擁有1,000,000條記錄的MySQL InnoDB表。 這太多了嗎？ 或者數據庫可以處理這個以及更多？ 我問，因為我注意到一些查詢（例如，從表中獲取最后一行）在表中的行（1秒）比在100行中慢（秒）。

Answer 1

我有一個帶有1000000個寄存器的MySQL InnoDB表。 這太多了嗎？

不，1,000,000 行 （AKA記錄）對於數據庫來說並不算太多。

我問，因為我注意到一些查詢（例如，獲取表的最后一個寄存器）在表中有100萬個寄存器比在100個寄存器中慢。

該聲明中有很多要考慮的因素。 通常的嫌疑人是：

1. 寫得不好的查詢
2. 不使用主鍵，假設表中存在一個主鍵
3. 設計不良的數據模型（表格結構）
4. 缺乏索引

Answer 2

我有一個超過97,000,000條記錄的數據庫（ 30GB數據文件 ），沒有問題。

只需記住定義和改進表索引 。

顯而易見， 1,000,000不是很多！ （但如果你沒有索引;是的，這很多）

Answer 3

使用'explain'檢查查詢並查看查詢計划是否有任何問題。

Answer 4

我認為這是一個常見的誤解 - 在數據庫可擴展性方面，大小只是等式的一部分。 還有其他問題很難（或更難）：

• 工作集有多大（即需要在內存中加載多少數據並積極處理）。 如果您只是插入數據然后對其執行任何操作，那么它實際上是一個很容易解決的問題。

• 需要什么級別的並發性？ 是否只有一個用戶插入/讀取，或者我們有多個客戶端同時運行？

• 需要什么級別的承諾/耐久性和性能的一致性？ 我們是否必須確保我們能夠兌現每次提交。 如果平均交易速度很快，或者我們是否希望確保所有交易都可靠地快速（六西格瑪質量控制，如http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization-）和 - 六西格瑪/ ）。

• 您是否需要執行任何操作問題，例如更改表模式？ 在InnoDB中，這是可能的，但速度極慢，因為它經常需要在前台創建一個臨時表（阻止所有連接）。

所以我要說明兩個限制問題：

• 您自己編寫查詢/具有良好索引的技能。
• 您可以忍受等待ALTER TABLE語句的痛苦程度。

Answer 5

如果您的意思是100萬行，那么這取決於索引的完成方式和硬件配置。 對於企業數據庫，甚至是體面設備上的開發數據庫，​​一百萬行不是很大的數量。

如果你的意思是100萬列（不確定甚至可能在MySQL中），那么是的，這看起來有點大，可能會引起問題。

Answer 6

寄存器？ 你是說記錄嗎？

如今，一百萬條記錄對於數據庫來說並不是什么大不了的事。 如果您遇到任何問題，可能不是數據庫系統本身，而是您正在運行它的硬件。 你很可能在硬件耗盡之前不會遇到數據庫問題。

現在，顯然有些查詢比其他查詢慢，但是如果兩個非常相似的查詢在非常不同的時間運行，則需要弄清楚數據庫的執行計划是什么並對其進行優化，即使用正確的索引，正確的規范化等。

順便說一句，表中沒有“最后”記錄這樣的東西，從邏輯的角度看它們沒有固有的順序。

Answer 7

我已經看到了具有數十億（索引）記錄的非分區表，這些表自行加入分析工作。 我們最終划分了這個東西，但老實說，我們沒有看到那么大的差異。

也就是說，那是在Oracle中，我沒有在MySQL中測試過那么多的數據。 索引是你的朋友:)

Answer 8

假設你用“寄存器”表示“記錄”沒有，它不是太多，MySQL可以很好地擴展，並且可以保存與你硬盤中的空間一樣多的記錄。

顯然，雖然搜索查詢會更慢。 除了確保字段被正確編入索引外，實際上沒有辦法解決這個問題。

Answer 9

表得到的越大（如在其中的更多行中），如果沒有索引，通常會運行較慢的查詢。 添加正確的索引后，您的查詢性能應該提高或至少不會隨着表的增長而降低。 但是，如果查詢本身在表變大時返回更多行，那么您將再次開始看到降級。

雖然1M行不是那么多，但它還取決於您在數據庫服務器上有多少內存。 如果表太大而無法由服務器緩存在內存中，則查詢速度會變慢。

Answer 10

由於使用排序合並方法對數據進行排序，因此使用提供的查詢將非常慢。

我建議重新考慮設計，以便您使用索引來檢索它或確保它已經以這種方式排序，因此不需要排序。