在相同業務場景下,架構設計和庫表索引設計會影響查詢性能,良好的設計可以提高查詢性能,反之會出現很多慢SQL(執行時間很長的SQL語句)。本文介紹導致慢SQL的原因和解決方案。

SQL異常

  • 原因及現象

    SQL異常的原因很多,例如庫表結構設計不合理、索引缺失、掃描行數太多等。

    您可以在控制臺的SQL洞察頁面,查看慢SQL的執行耗時、執行次數等信息。

  • 解決方案

    根據實際業務情況優化SQL。具體操作,請參見SQL優化。

實例瓶頸

  • 原因及現象

    實例到達瓶頸的原因一般有如下幾種:

    • 業務量持續增長而沒有擴容。
    • 硬件老化,性能有損耗。
    • 數據量一直增加,數據結構也有變化,導致原來不慢的SQL變成慢SQL。

    您可以在控制臺的監控與報警頁面,單擊標準監控頁簽,在資源監控內可以查看實例的資源使用情況。如果資源使用率各項指標都接近100%,可能是實例到達了瓶頸。

  • 解決方案

    判斷實例是否到達瓶頸,較好的方法是先測試出實例的性能基準值,例如用SysBench進行基準測試,復雜場景下的QPS和TPS很少會超過基準值。

    確認實例到達瓶頸后,建議升級實例規格。具體操作,請參見變更配置。

版本升級

  • 原因及現象

    實例升級版本可能會導致SQL執行計劃發生改變,執行計劃中連接類型從好到壞的順序是system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>all。更多信息,請參見MySQL官方文檔。

    range和index連接類型時,如果SQL請求變慢,業務又不斷重發請求,導致并行SQL查詢比較多,會導致應用線程釋放變慢,最終連接池耗盡,影響整個業務。

    您可以在控制臺的監控與報警頁面,單擊標準監控頁簽,在資源監控內可以查看實例的連接數情況。

  • 解決方案

    根據執行計劃分析索引使用情況、掃描的行數等,預估查詢效率,重構SQL語句、調整索引,提升查詢效率。具體操作,請參見SQL優化

參數設置不當

  • 原因及現象

    參數innodb_buffer_pool_instances、join_buffer_size等設置不當會導致性能變慢。

    您可以在控制臺的參數設置頁面,單擊修改歷史頁簽,查看實例的參數修改情況。

    修改歷史
  • 解決方案

    調整相關參數,使其適合業務場景。

緩存失效

  • 原因及現象

    緩存可以很好地承擔大量查詢,但是并不能保證緩存命中率100%,如果緩存失效,也會有大量的查詢路由到數據庫端,導致性能下降。

    您可以在控制臺的監控與報警頁面,單擊標準監控頁簽,在引擎監控內可以查看實例的緩存命中率、QPS、TPS等。

  • 解決方案

    可以使用Thread PoolFast Query Cache、自動SQL限流等功能提高性能。

批量操作

  • 原因及現象

    如果有大批量的數據導入、刪除、查詢操作,會導致SQL執行變慢。

    可以從磁盤空間、SQL洞察或者慢查詢里找到對應語句。例如查看Binlog大小,正常情況單個Binlog大小是500 MB,如果有超過500 MB的,可以查看是否有異常。

    您也可以在控制臺的監控與報警頁面,單擊標準監控頁簽,在資源監控引擎監控內可以查看實例的磁盤空間、IOPS、事務等情況。

    Binlog
  • 解決方案

    在業務低峰期執行大批量操作,或將大批量操作拆分后分批執行。

未關閉事務

  • 原因及現象

    如果某個任務突然變慢,查看CPU和IOPS的使用率并不高,而且活躍會話持續增多,通常是因為存在未關閉的事務。

  • 解決方案

    檢查導致事務沖突的鎖并中止對應的SQL語句。

定時任務

  • 原因及現象
    如果實例負載隨時間有規律性變化,可能是存在定時任務。
    說明 您可以在監控與報警頁面的標準監控頁簽查看相關監控信息。
  • 解決方案

    調整定時任務的執行時間,建議在業務低峰期執行。

總結

RDS上定位慢SQL的主要方法如下:

結合RDS提供的這些功能,可以有效幫助您快速定位甚至自動解決慢SQL問題。