談談SQL慢查詢的解決思路

最近，在運維部及DBA同事的幫助和你們的共同努力下，對項目中的慢SQL進行了優化和修正，效果仍是很明顯的，在此給你們點一個大大的贊。爲了讓咱們在SQL的處理上更爲合理，造成可實踐、可借鑑、可參考優化的方案，我在這裏梳理一下慢SQL的解決思路，供你們參考。

慢SQL的系統表現

首先，咱們如何判別系統中遇到了SQL慢查詢問題？我的認爲慢SQL有以下三個特徵：

1，數據庫CPU負載高。通常是查詢語句中有不少計算邏輯，致使數據庫cpu負載。

2，IO負載高致使服務器卡住。這個通常和全表查詢沒索引有關係。

3，查詢語句正常，索引正常可是仍是慢。若是表面上索引正常，可是查詢慢，須要看看是否索引沒有生效。

開啓SQL慢查詢的日誌

若是你的系統出現了上述狀況，而且你不是用的阿里雲的RDS這樣的產品，那麼下一步就須要打開Mysql的慢查詢日誌來進一步定位問題。MySQL 提供了慢查詢日誌，這個日誌會記錄全部執行時間超過 long_query_time（默認是10s）的 SQL 及相關的信息。

要開啓日誌，須要在 MySQL 的配置文件 my.cnf 的 [mysqld] 項下配置慢查詢日誌開啓，以下所示：

[mysqld]slow_query_log=1
slow_query_log_file=/var/log/mysql/log-slow-queries.log
long_query_time=2複製代碼

在實際項目中，因爲生成的慢查詢的日誌可能會特別大，分析起來不是很

方便，因此Mysql官方也提供了 mysqldumpslow 這個工具，方便咱們分析慢查詢日誌，感興趣的同窗能夠自行到Mysql官方進行查閱。

SQL調優

有些SQL雖然出如今慢查詢日誌中，但未必是其自己的性能問題，多是由於鎖等待，服務器壓力高等等。須要分析SQL語句真實的執行計劃，而不是看從新執行一遍SQL時，花費了多少時間，由自帶的慢查詢日誌或者開源的慢查詢系統定位到具體的出問題的SQL，而後使用Explain工具來逐步調優，瞭解 MySQL 在執行這條數據時的一些細節，好比是否進行了優化、是否使用了索引等等。基於 Explain 的返回結果咱們就能夠根據 MySQL 的執行細節進一步分析是否應該優化搜索、怎樣優化索引。

關於索引的建立及優化原則，我的特別推薦美團點評技術團隊的幾點總結，講得特別好，特意引用一下：

1. 最左前綴匹配原則，很是重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是創建(a,b,c,d)順序的索引，d是用不到索引的，若是創建(a,b,d,c)的索引則均可以用到，a,b,d的順序能夠任意調整；

2. =和in能夠亂序，好比a = 1 and b = 2 and c = 3 創建(a,b,c)索引能夠任意順序，mysql的查詢優化器會幫你優化成索引能夠識別的形式；

3. 儘可能選擇區分度高的列做爲索引,區分度的公式是count(distinct col)/count(*)，表示字段不重複的比例，比例越大咱們掃描的記錄數越少，惟一鍵的區分度是1，而一些狀態、性別字段可能在大數據面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不一樣，這個值也很難肯定，通常須要join的字段咱們都要求是0.1以上，即平均1條掃描10條記錄；

4. 索引列不能參與計算，保持列「乾淨」，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，緣由很簡單，b+樹中存的都是數據表中的字段值，但進行檢索時，須要把全部元素都應用函數才能比較，顯然成本太大。因此語句應該寫成create_time = unix_timestamp(’2014-05-29’);

5. 儘可能的擴展索引，不要新建索引。好比表中已經有a的索引，如今要加(a,b)的索引，那麼只須要修改原來的索引便可。

一點總結

基於本文的思路，關於SQL慢查詢的解決能夠按照如下的步驟執行：

1. 打開慢日誌查詢，肯定是否有SQL語句佔用了過多資源，若是是，在不改變業務原意的前提下，對insert、group by、order by、join等語句進行優化。

2. 考慮調整MySQL的系統參數： innodb_buffer_pool_size、innodb_log_file_size、table_cache等。

3. 肯定是不是由於高併發引發行鎖的超時問題。

4. 若是數據量過大，須要考慮進一步的分庫分表，能夠參見以前的文章1和 文章2 。

掃描二維碼或手動搜索微信公衆號【架構棧】： ForestNotes

歡迎轉載，帶上如下二維碼便可