什么是慢查詢
什么是MySQL慢查詢呢？就是查詢的SQL語句耗費較長時間。具體耗費多久算慢查詢呢？這其實因業務而異，有些慢查詢的閾值long_query_time是0.5s，有些的閾值可能是2s，即查詢的時間超過這個閾值即視為慢查詢。
慢查詢的危害
- 用戶體驗差。
- 占用MySQL內存，影響性能。
- 并行查詢增多，連接數耗盡。
- 造成業務變更DDL堵塞，備份失敗等。
慢查詢常見場景
在相同業務場景下，架構設計和庫表索引設計會影響查詢性能，良好的設計可以提高查詢性能，反之會出現很多慢SQL。造成慢SQL的原因大概一下幾大類：
SQL不合理
-
原因及現象
SQL異常的原因很多，例如庫表結構設計不合理、索引缺失或沒有利用好索引、掃描行數太多，單表數據量太大，使用了磁盤臨時表，filesort查詢等。
您可以在MySQL控制臺的慢日志頁面，查看執行緩慢的SQL，慢SQL的執行耗時，以及相關執行計劃等信息，請參見查看慢日志。 -
解決方案
根據實際業務情況優化SQL，比如對查詢進行優化，應盡量避免全表掃描，避免like '%abc%'模糊查詢，避免在 where 子句中對字段進行表達式操作，盡量使用數字型字段等等。
實例到達瓶頸
-
原因及現象
實例到達瓶頸的原因一般有如下幾種：- 業務量經過一段時間持續增長而沒有擴容實例規格。
- 服務器的硬件老化，性能有損耗。
- 業務表數據量一直增加導致單表數據量太大，表數據結構也有變化，導致原來不慢的SQL變成慢SQL。
您可以在控制臺的查看實例的資源使用情況。如果CPU，磁盤IO等資源使用率各項指標都接近100%，可能是實例到達了瓶頸。具體操作，請參見查看監控指標。
-
解決方案
確認是實例到達瓶頸后，建議升級實例規格。具體操作，請參見規格擴容。
內核版本升級
- 原因及現象
實例升級版本有可能會導致SQL執行計劃發生改變，explain的執行計劃中連接類型從好到壞的順序是system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>all。如果SQL請求變慢，業務又不斷重發請求，導致并行SQL查詢比較多，會導致應用線程釋放變慢，最終連接數耗盡，影響整個業務。更多執行計劃信息，請參見MySQL官方文檔。
您可以在控制臺的查看實例的當前連接數指標。具體操作，請參見查看監控指標。 - 解決方案
請在控制臺慢SQL監控中查看執行計劃。根據執行計劃分析索引使用情況、預估掃描的行數等，預估查詢效率，重構SQL語句、調整索引，提升查詢效率。
參數設置不當
- 原因及現象
部分SQL查詢慢，可能是一些相關參數（如join_buffer_size，sort_buffer_size，tmp_table_size等）設置不當會導致性能變慢。
您可以在控制臺查看實例的參數修改情況。具體操作，請參見修改參數組。 - 解決方案
調整全局相關參數，使其適合響應的業務場景或者業務SQL前設置會話級相關參數。具體請參見關系數據庫MySQL版參數調優建議。
批量操作
-
原因及現象
如果有進行大批量的數據遷移導入、刪除，以及查詢等操作，會導致SQL執行變慢，磁盤IO使用率增大，磁盤使用量突增等。
您可以在控制臺查看實例的磁盤總大小、磁盤使用量、IOPS等指標。具體操作，請參見查看監控指標。
-
解決方案
建議在業務低峰期執行大批量操作，或將大批量操作拆分后分批執行。
定時任務
-
原因及現象
如果實例負載監控數據隨時間有規律性變化，可能是存在定時任務。
您可以在控制臺查看實例監控DML相關的Delete語句、Update語句，Insert語句、Insert_Select語句、Replace語句、Replace_Select語句、Select語句等語句的執行頻率等指標，判斷是否有規律性變化。具體操作，請參見查看監控指標。
-
解決方案
調整定時任務的執行時間，建議在業務低峰期執行定時任務。
