使用MySQL進行報告 - 最簡單的查詢耗時太長

我在具有250 000行的Amazon RDS實例上有一個MySQL表。當我嘗試使用MySQL進行報告 - 最簡單的查詢耗時太長

SELECT * FROM tableName

不附加任何條件（只是用於測試，正常查詢指定我需要的列，但我最需要他們的），查詢需要20到60秒之間執行。這將是我的報告的基本查詢，並且報告應該在60秒內運行，所以我認爲這不會奏效（當我添加連接時，它會超時）。報告在我們的小型測試環境中運行時沒有任何問題。

難道是因爲MySQL試圖鎖定表並等待所有寫入完成而需要這麼久嗎？這張桌子上可能有很多寫作。我正在做一個MySQL從屬查詢，因爲我不想用我的查詢鎖定生產系統。

我對於關係數據庫有多少行沒有經驗。是250 000行約30列（varchar，日期和整數類型）多少？
我怎樣才能加速比這個查詢（硬件，軟件，查詢優化...）
我可以告訴MySQL的，我不關心數據可能是不一致的（這是一個快照從報告數據庫）
這個查詢是否有可能在60秒內運行，還是我必須調整目標？

來源

2013-08-27 Paul Weber

將索引添加到表中可能會有所幫助。 – EmCo

您正在使用哪種引擎？ InnoDB，MyISAM？他們都不應該有任何處理250K行的問題。檢查表格是否已正確編制索引。如果您使用的是MyISAM，那麼您可以增加關鍵緩衝區大小 – Barranka

我正在使用InnoDB。對於一個SELECT（*）我該怎麼索引（這基本上是我的應用程序將要做的事情，我需要轉儲一些連接表，但它們都被索引）。 –

請記住，MySQL必須準備好結果集並將其傳輸到客戶端。在你的情況下，它可能需要200MB的數據才能穿越連接，所以20秒並不差。默認情況下，大多數庫在將其轉發給應用程序之前等待收到的整個結果。

要加快速度，只能獲取您需要的列，或者以LIMIT以大塊形式執行。SELECT *通常表示某人正在超級懶惰並且根本沒有進行優化。

如果您的圖書館支持流式結果集，請使用它，因爲您可以立即開始獲取數據。它將允許您在進入時迭代行，而不會緩衝整個結果。

來源

2013-08-27 15:26:18 tadman

+1。。。流媒體是一個很好的建議。 –

我能夠與客戶交談並獲得他需要的用戶標準。所以我們下降到大約250個用戶，這些用戶在一秒鐘之內返回。我們需要的所有連接再次增加到60秒，但我們加入了有數百萬條記錄的表格，所以這就是O.K. 所以建議不要「取得所有的行!!!」是正確的，我會將這個答案標記爲已接受。 –

對MYSQL視圖添加一個小的註釋：如果您有一個執行「SELECT * FROM originalTable」的表的VIEW並在VIEW上執行帶有WHERE子句的選擇查詢，則VIEW將首先執行SELECT，然後執行SELECT它在接收到的結果集上的哪個位置。即使完整的結果不必經過網絡，生成此結果集可能也需要很長時間。我一直認爲MySQL是非常明智的，可以將WHERE子句應用到原始SELECT的視圖上，但現在我明智了，並且知道MySQL的視圖非常愚蠢。 –

我不應該真的使用*作爲通配符。選擇您實際需要的字段，然後創建組合的這些字段的索引。

來源

2013-08-27 15:19:36

好的建議，但在這種特殊情況下，我真的需要本表中的所有字段，因爲它是專門爲此報告生成的。在真正的查詢中，我甚至全部指定它們（以獲取別名），但這只是一個測試查詢來獲得性能估計。您的建議是爲表格中的所有字段創建索引嗎？我不認爲這會是明智的，是嗎？ –

@PaulWeber如果這是最可能的網絡延遲的原因。使用存儲過程獲取數據庫來完成所有沉重的工作，您只需發送參數，數據庫服務器返回結果。 –

對於MySQL來說，一張250,000行的表對MySQL來說不算太大。

但是，等待這些行返回到應用程序確實需要時間。這是網絡時間，你和亞馬遜之間可能有很多跳躍。

除非您的報告是真的要處理所有的數據，用一個簡單的查詢檢查數據庫的性能，如：

select count(*) from table;

編輯：

你的問題是不太可能是由於到數據庫。這可能是由於網絡流量。正如另一個答案中提到的，流式傳輸可能會解決這個問題您也可以使用數據格式來將總大小降低到更合理的值。

最後一個步驟是將數據保存在文本文件中，壓縮文件，將其移動並解壓縮。雖然這聽起來像很多工作，但您可能會獲得5倍 - 10倍的數據壓縮，從而節省傳輸時間，並且在處理其餘部分時仍可大幅提高性能。

來源

2013-08-27 15:20:14

那麼，報表將不得不處理所有的數據，因爲表中包含我們需要的數據（減去一些需要連接的數據）。我們只需要一種有效的方式來以某種方式獲取它。 –

@PaulWeber。。。你可能應該在數據庫中進行處理並返回一個更小的結果集。返回所有行以在應用程序中執行處理，而不利於使用數據庫的目的。 –

解釋：該數據庫包含一份關於我們所有用戶的報告，並且客戶希望用戶報告所有用戶的數據。所以我們給他訪問這個數據庫... 但這是一個好點，也許我可以通過查詢篩選出最重要的用戶。 AC仍然是所有25萬行的報告。 –

我從我的客戶那裏得到了更新的規格，並且能夠減少用戶返回到250的數量，儘管它在60秒內完成了（有很多JOINS）。

所以也許答案是真的：儘量不要轉儲整個表的查詢，只提取您需要的確切數據。客戶端具有SQL訪問權限，他將不得不更新他的查詢，因此只返回相關用戶。

來源

2013-08-28 08:02:34

如果您有成千上萬的行，另一個選項是實現分頁。如果結果數據直接用於報告，沒有人可以在單個鏡頭中查看超過100行。

來源

2015-10-16 06:07:12 user3732995

使用MySQL進行報告 - 最簡單的查詢耗時太長

回答

相關問題