談談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 的執行細節進一步分析是否應該優化搜尋、怎樣優化索引。

最左字首匹配原則，非常重要的原則，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的順序可以任意調整；

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

盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃瞄的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別字段可能在大資料面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃瞄10條記錄；

索引列不能參與計算，保持列「乾淨」，比如from_unixtime(create_time) = 』2014-05-29』就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的字段值，但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp(』2014-05-29』);

盡量的擴充套件索引，不要新建索引。比如表中已經有a的索引，現在要加(a,b)的索引，那麼只需要修改原來的索引即可。

一點總結

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

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

3. 確定是否是因為高併發引起行鎖的超時問題。

4. 如果資料量過大，需要考慮進一步的分庫分表。

談談SQL慢查詢的解決思路

SQL查詢慢的解決思路

sql查詢慢查詢

慢Sql語句優化思路

談談SQL慢查詢的解決思路

SQL查詢慢的解決思路

sql查詢慢 查詢

慢Sql語句優化思路

相關推薦

sql查詢慢查詢