我如何使這個查詢運行得更快？

Question

我該如何讓這個查詢運行得更快......？

 
SELECT account_id, 
      account_name, 
      account_update, 
      account_sold, 
      account_mds, 
      ftp_url,   
      ftp_livestatus, 
      number_digits, 
      number_cw, 
      client_name, 
      ppc_status, 
      user_name 
FROM  
     Accounts, 
     FTPDetails, 
     SiteNumbers, 
     Clients, 
     PPC, 
     Users 

WHERE Accounts.account_id = FTPDetails.ftp_accountid 
AND  Accounts.account_id = SiteNumbers.number_accountid 
AND  Accounts.account_client = Clients.client_id  
AND  Accounts.account_id = PPC.ppc_accountid 
AND  Accounts.account_designer = Users.user_id 
AND  Accounts.account_active = 'active' 
AND  FTPDetails.ftp_active = 'active' 
AND  SiteNumbers.number_active = 'active' 
AND  Clients.client_active = 'active'  
AND  PPC.ppc_active = 'active' 
AND  Users.user_active = 'active' 
ORDER BY 
     Accounts.account_update DESC 

感謝提前:)

EXPLAIN查詢結果：

我真的沒有任何外鍵設置...我試圖避免對數據庫進行修改，因爲它不得不完成修改即將進行大修。

只有主鍵是每個表的ID例如account_id，ftp_id，ppc_id ...

Answer 1

使用EXPLAIN找出可以使用哪個索引以及實際使用哪個索引。必要時創建一個適當的索引。

如果FTPDetails.ftp_active只有兩個有效條目'active'和'inactive'，請使用BOOL作爲數據類型。

作爲一個方面說明：我強烈使用明確的建議加入的，而不是含蓄的：

SELECT 
    account_id, account_name, account_update, account_sold, account_mds, 
    ftp_url, ftp_livestatus, 
    number_digits, number_cw, 
    client_name, 
    ppc_status, 
    user_name 
FROM Accounts 
INNER JOIN FTPDetails 
    ON Accounts.account_id = FTPDetails.ftp_accountid 
    AND FTPDetails.ftp_active = 'active' 
INNER JOIN SiteNumbers 
    ON Accounts.account_id = SiteNumbers.number_accountid 
    AND SiteNumbers.number_active = 'active' 
INNER JOIN Clients 
    ON Accounts.account_client = Clients.client_id 
    AND Clients.client_active = 'active' 
INNER JOIN PPC 
    ON Accounts.account_id = PPC.ppc_accountid 
    AND PPC.ppc_active = 'active' 
INNER JOIN Users 
    ON Accounts.account_designer = Users.user_id 
    AND Users.user_active = 'active' 
WHERE Accounts.account_active = 'active' 
ORDER BY Accounts.account_update DESC 

這使得查詢更加易讀，因爲聯接條件是接近被加入了表的名稱。

Answer 2

說明，基準不同的選項。對於初學者來說，我確信有幾個查詢會比這個怪物更快。首先，因爲查詢優化器將花費大量時間來檢查什麼連接順序是最好的（5！= 120個可能性）。其次，像SELECT ... WHERE ....active = 'active'這樣的查詢將被緩存（儘管它取決於數據量的變化）。

Answer 3

指標

• 你需要 - 至少 - 對在一個JOIN條件下使用的每個字段的索引。

• 出現在WHERE或GROUP BY或ORDER BY子句中的字段上的索引大部分時間也很有用。

• 當在一個表中JOIN（或WHERE或GROUP BY或ORDER BY）中使用兩個或更多字段時，這些（兩個或更多）字段的複合（組合）索引可能比獨立索引更好。例如在SiteNumbers表中，可能的索引是化合物(number_accountid, number_active)或(number_active, number_accountid)。

• 布爾型（ON/OFF，活動/非活動）字段中的條件有時會減慢查詢速度（因爲索引不具有選擇性，因此不是很有用）。在這種情況下，重構（父親正常化）表格是一種選擇，但可能可以避免增加的複雜性。

---

除了一般的建議（檢查解釋計劃，增加在需要的索引，查詢的測試變化），

我注意到，在您的查詢存在部分笛卡爾乘積。表Accounts與三個表FTPDetails，SiteNumbers和PPC有一對多的關係。這樣做的結果是，如果您有例如1000個帳戶，並且每個帳戶與10個FTPDetails，20個SiteNumbers和3個PPC相關，則每個帳戶600行（10x20x3的產品）將返回查詢。共有600K行，其中有許多數據被複制。

您可以改爲將基本數據（帳戶和其他表）的查詢拆分爲三加一。這樣，只有34K行數據（具有較小的長度）的將被轉移：

Accounts JOIN Clients JOIN Users 
    (with all fields needed from these tables) 
    1K rows 

Accounts JOIN FTPDetails 
    (with Accounts.account_id and all fields from FTPDetails) 
    10K rows 

Accounts JOIN SiteNumbers 
    (with Accounts.account_id and all fields from SiteNumbers) 
    20K rows 

Accounts JOIN PPC 
    (with Accounts.account_id and all fields from PPC) 
    3K rows 

，然後使用從在客戶端側的4和查詢數據，以顯示組合的信息。

---

---

我想補充以下指標：

Table Accounts 
    index on (account_designer) 
    index on (account_client) 
    index on (account_active, account_id) 
    index on (account_update) 

Table FTPDetails 
    index on (ftp_active, ftp_accountid) 

Table SiteNumbers 
    index on (number_active, number_accountid) 

Table PPC 
    index on (ppc_active, ppc_accountid) 

Answer 4

你的一個主要問題是在這裏：x.y_active = 'active'

問題：低基數
有源現場是一個帶有2個可能值的布爾型字段，因此它具有非常低的基數。 MySQL（或任何有關此問題的SQL在30％或更多行具有相同值時不會使用索引）。
強制索引是無用的，因爲它會讓你的查詢更慢，而不是更快。

解決方案：你的分區表
一種解決方案是在active列分區你的表。
這會排除所有非活動字段的考慮因素，並會使select的行爲就好像您實際上在xxx-active字段中具有工作索引一樣。

旁註
請永遠不要使用隱where連接，它太容易出錯，consufing是有用的。
改爲使用類似Oswald's answer的語法。

鏈接：
基數：http://en.wikipedia.org/wiki/Cardinality_(SQL_statements)
基數和索引：http://www.bennadel.com/blog/1424-Exploring-The-Cardinality-And-Selectivity-Of-SQL-Conditions.htm
MySQL分區：http://dev.mysql.com/doc/refman/5.5/en/partitioning.html