索引和加速「派生」查詢

Question

我最近注意到，我有一個查詢運行速度相當慢，幾乎每查詢1秒。

查詢看起來像這樣

 
SELECT eventdate.id, 
     eventdate.eid, 
     eventdate.date, 
     eventdate.time, 
     eventdate.title, 
     eventdate.address, 
     eventdate.rank, 
     eventdate.city, 
     eventdate.state, 
     eventdate.name, 
     source.link, 
     type, 
     eventdate.img 
FROM source 
RIGHT OUTER JOIN 
(
    SELECT event.id, 
      event.date, 
      users.name, 
      users.rank, 
      users.eid, 
      event.address, 
      event.city, 
      event.state, 
      event.lat, 
      event.`long`, 
      GROUP_CONCAT(types.type SEPARATOR ' | ') AS type 
    FROM event FORCE INDEX (latlong_idx) 
    JOIN users ON event.uid = users.id 
    JOIN types ON users.tid=types.id 
    WHERE `long` BETWEEN -74.36829174058 AND -73.64365405942 
    AND lat BETWEEN 40.35195025942 AND 41.07658794058 
    AND event.date >= '2009-10-15' 
    GROUP BY event.id, event.date 
    ORDER BY event.date, users.rank DESC 
    LIMIT 0, 20 
)eventdate 
ON eventdate.uid = source.uid 
AND eventdate.date = source.date; 

和說明的是

 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key   | key_len | ref       | rows | Extra       | 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 
| 1 | PRIMARY  |   | ALL | NULL   | NULL  | NULL | NULL       | 20 |         | 
| 1 | PRIMARY  | source  | ref | iddate_idx | iddate_idx | 7  | eventdate.id,eventdate.date | 156 |         | 
| 2 | DERIVED  | event  | ALL | latlong_idx | NULL  | NULL | NULL       | 19500 | Using temporary; Using filesort | 
| 2 | DERIVED  | types  | ref | eid_idx  | eid_idx  | 4  | active.event.id    | 10674 | Using index      | 
| 2 | DERIVED  | users  | eq_ref | id_idx  | id_idx  | 4  | active.types.id    |  1 | Using where      | 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 

我已經使用上的經緯度「力指數」嘗試過，但似乎並沒有加快速度所有。

它是導致慢響應的派生表嗎？如果是這樣，有沒有辦法提高這個性能？

--------編輯------------- 我已經嘗試改善格式化，以使其更具可讀性，以及

我運行同樣的查詢只改變「WHERE語句

 
WHERE users.id = (
SELECT users.id 
FROM users 
WHERE uidname = 'frankt1' 
ORDER BY users.approved DESC , users.rank DESC 
LIMIT 1) 
AND date & gt ; = '2009-10-15' 
GROUP BY date 
ORDER BY date) 

該查詢0.006英寸秒運行一次

的解釋貌似

 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 
| id | select_type | table  | type | possible_keys | key   | key_len | ref       | rows | Extra   | 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 
| 1 | PRIMARY  |   | ALL | NULL   | NULL   | NULL | NULL       | 42 |    | 
| 1 | PRIMARY  | source  | ref | iddate_idx | iddate_idx | 7  | eventdate.id,eventdate.date | 156 |    | 
| 2 | DERIVED  | users  | const | id_idx  | id_idx  | 4  |        | 1 |    | 
| 2 | DERIVED  | event  | range | eiddate_idx | eiddate_idx | 7  | NULL       | 24 | Using where | 
| 2 | DERIVED  | types  | ref | eid_idx  | eid_idx  | 4  | active.event.bid    | 3 | Using index | 
| 3 | SUBQUERY | users  | ALL | idname_idx | idname_idx | 767  |        | 5 | Using filesort | 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 

Answer 1

清理這個龐大的SQL語句的唯一方法是返回到繪圖板並仔細處理數據庫設計和需求。只要你開始加入6個表格並使用內部選擇，你應該期待令人難以置信的執行時間。

作爲一個開始，請確保您的所有id字段都已編入索引，但要確保您的設計有效，請更好。我不知道從哪裏開始查看您的SQL - 即使在我爲您重新格式化之後。

請注意，'使用索引'意味着您在創建或更改正在使用的表時需要發出正確的說明。例如參見MySql 5.0 create indexes