MySQL查詢花費很長時間

Question

我對包含大約14百萬條記錄的表進行了非常簡單的查詢，這些記錄大約需要30分鐘才能完成。以下是查詢：

select a.switch_name, a.recording_id, a.recording_date, a.start_time, 
     a.recording_id, a.duration, a.ani, a.dnis, a.agent_id, a.campaign, 
     a.call_type, a.agent_call_result, a.queue_name, a.rec_stopped, 
     a.balance, a.client_number, a.case_number, a.team_code 
from recording_tbl as a 
where client_number <> '1234567' 

過濾client_number似乎是罪魁禍首，並且列確實有索引。我不知道還有什麼可以嘗試的。

Answer 1

您可以從client_number創建INDEX開始，看看它是如何提供幫助的，但是在使用EXPLAIN命令分析問題時可以獲得最佳結果。

http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html

Answer 2

也許......

where client_number = '1234567' 

...會快一點。

Answer 3

如果客戶編號存儲爲數字字段，然後

where client_number = 1234567 

可能更快，如果字符串比較是導致它做一個演員和可能防止正在使用的索引。

Answer 4

表是myisam還是innodb？如果innodb大量增加innodb緩衝區，那麼整個表都可以放入內存。如果myisam好，它應該通過操作系統緩存緩衝區自動加載到內存中。安裝更多的RAM。安裝更快的磁盤驅動器這些似乎是你唯一的解決方案，考慮到你正在做整個表掃描（減去任何客戶端號碼似乎是你的測試客戶端ID？）

它需要一段時間加載到RAM以及所以不要期望它作爲db啓動之後。

Answer 5

您的查詢是在查詢中的一個表上執行全表掃描，recording_tbl。我是，假設這是一張表，而不是一個視圖，因爲「tbl」前綴。如果這是一個視圖，那麼你需要優化視圖。

有沒有必要看看解釋。索引不太可能有用，除非99％左右的記錄具有1234567的client_number。由於稱爲抖動的現象，索引可能使事情發揮作用。

您的問題是小型硬件或MySQL查詢引擎的underellocated資源。我首先會看看引擎的緩衝區，然後是處理器的硬件和帶寬。

Answer 6

爲什麼你需要返回14m行？ （我假設大多數記錄沒有你正在搜索的ID）。 如果您不需要需要所有14m行，請將LIMIT添加到查詢的末尾。更少的行 - >更少的內存 - >更快的查詢。

實施例：

select a.switch_name, a.recording_id, a.recording_date, a.start_time, 
    a.recording_id, a.duration, a.ani, a.dnis, a.agent_id, a.campaign, 
    a.call_type, a.agent_call_result, a.queue_name, a.rec_stopped, 
    a.balance, a.client_number, a.case_number, a.team_code 
from recording_tbl as a 
where client_number <> '1234567' 
LIMIT 1000 

將返回第一1000行。

這裏有一個如何在不同的SQL RDBMS返回前N行的比較： http://www.petefreitag.com/item/59.cfm