概述：

交代一下背景，這算是一次專案經驗吧，屬於公司一個已上線平臺的功能，這算是離職人員挖下的坑，隨著資料越來越多，原本的SQL查詢變得越來越慢，使用者體驗特別差，因此SQL優化任務交到了我手上。
這個SQL查詢關聯兩個資料表，一個是攻擊IP使用者表主要是記錄IP的資訊，如第一次攻擊時間，地址，IP等等，一個是IP攻擊次數表主要是記錄每天IP攻擊次數。而需求是獲取某天攻擊IP資訊和次數。（以下SQL語句測試均在測試伺服器上上，正式伺服器的效能好，查詢時間快不少。）

準備：

查看錶的行數：


未優化前SQL語句為：

SELECT
    attack_ip,
    country,
    province,
    city,
    line,
    info_update_time AS
 
 attack_time,
    sum( attack_count ) AS attack_times 
FROM
    `blacklist_attack_ip`
    INNER JOIN `blacklist_ip_count_date` ON `blacklist_attack_ip`.`attack_ip` = `blacklist_ip_count_date`.`ip` 
WHERE
    `attack_count` > 0 
    AND `date` BETWEEN '2017-10-13 00:00:00' 
    AND '2017-10-13 23:59:59' 
GROUP
 
 BY
    `ip`
    LIMIT 10 OFFSET 1000

先EXPLAIN分析一下：

這裡看到索引是有的，但是IP攻擊次數表blacklist_ip_count_data也用上了臨時表。那麼這SQL不優化直接第一次執行需要多久（這裡強調第一次是因為MYSQL帶有快取功能，執行過一次的同樣SQL，第二次會快很多。）

實際查詢時間為300+秒，這完全不能接受呀，這還是沒有其他搜尋條件下的。
那麼我們怎麼優化呢，索引既然走了，我嘗試一下避免臨時表，這時我們先了解一下臨時表跟group by的使聯絡:

查找了網上一些部落格分析GROUP BY 與臨時表的關係 :
　　1. 如果GROUP BY 的列沒有索引,產生臨時表.
　　2. 如果GROUP BY時,SELECT的列不止GROUP BY列一個,並且GROUP BY的列不是主鍵 ,產生臨時表.
　　3. 如果GROUP BY的列有索引,ORDER BY的列沒索引.產生臨時表.
　　4. 如果GROUP BY的列和ORDER BY的列不一樣,即使都有索引也會產生臨時表.
　　5. 如果GROUP BY或ORDER BY的列不是來自JOIN語句第一個表.會產生臨時表.
　　6. 如果DISTINCT 和 ORDER BY的列沒有索引,產生臨時表.

仔細按照上面分析一下，這SQL可能是因為第二條導致的，blacklist_ip_count_date這個表的確主鍵不是IP，SELECT是多列的，那麼我們試試單獨提出單表測試能不能避免臨時表：

很遺憾，並不能避免，但是我們仔細看看這EXPLAIN 裡面的KEY 分析，用的索引是date單欄位的索引。這好像就是導致了第一條的問題了，相當於GROUP BY沒有用索引。那麼我們試試強制使用IP單欄位的索引呢？

這裡看來的確是索引的問題，導致了臨時表啊，然而再看看ROWS的數量，原來的9W變成了1552W，這不是不是撿了芝麻掉了西瓜嗎？
這裡單列索引 避免了臨時表可是聯絡的行數又增加了，那麼我們再試試複合索引呢？
於是建立attack_count、date、ip的複合索引index_Acount_date_ip

ROWS的行數770W而且還是有臨時表，看來這複合索引也是不可取。
到此，避免臨時表方法失敗了，我們得從其他角度想想如何優化。
其實，9W的臨時表並不算多，那麼為什麼導致會這麼久的查詢呢？我們想想這沒優化的SQL的執行過程是怎麼樣的呢？

網上搜索得知內聯表查詢一般的執行過程是：
1、執行FROM語句
2、執行ON過濾
3、新增外部行
4、執行where條件過濾
5、執行group by分組語句
6、執行having
7、select列表
8、執行distinct去重複資料
9、執行order by字句
10、執行limit字句

這裡得知，Mysql 是先執行內聯表然後再進行條件查詢的最後再分組,那麼想想這SQL的條件查詢和分組都只是一個表的，內聯後資料就變得臃腫了，這時候再進行條件查詢和分組是否太吃虧了，我們可以嘗試一下提前進行分組和條件查詢，實現方法就是子查詢聯合內聯查詢。

這裡EXPLAIN看來，只是多了子查詢，ROWS和臨時表都沒有變化。那麼我們看看實際的效果呢？

可見，取出來的資料完全一模一樣，可是優化後效率從原來的330秒變成了0.28秒，這裡足足提升了1000多倍的速度。這也基本滿足了我們的優化需求。
估計到這裡，你猜這裡就是全部的優化方案？不不不，整個優化過程怎麼可能只是發現一個優化方案。還有其他方案我會分開文章寫，具體請檢視我的下一篇文章MYSQL一次千萬級連表查詢優化（二）。

總結：

整個過程中我們得知，其實EXPLAIN有時候並不能指出你的SQL的所有問題，有一些隱藏問題必須要你自己思考，正如我們這個例子，看起來臨時表是最大效率低的源頭，但是實際上9W的臨時表對MYSQL來說不足以掛齒的。我們進行內聯查詢前，最好能限制連的表大小的條件都先用上了，同時儘量讓條件查詢和分組執行的表儘量小。感謝您們的閱讀，如果有更好的方案，歡迎留言交流！！！