synch/mutex/innodb/fil_mutex - Amazon Aurora
支援的引擎版本Context等待變多的可能原因動作

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

synch/mutex/innodb/fil_mutex

當工作階段正在等待存取資料表空間記憶體快取時，synch/mutex/innodb/fil_system_mutex 事件便會發生。

支援的引擎版本

下列引擎版本支援這個等待事件資訊：

  • Aurora MySQL 2 版和 3 版

Context

InnoDB 會使用資料表空間來管理資料表和日誌檔案的儲存區域。「資料表空間記憶體快取」是全域記憶體結構，用於維護資料表空間的相關資訊。MySQL 會使用 synch/mutex/innodb/fil_system_mutex 等待來控制資料表空間記憶體快取的並行存取。

事件 synch/mutex/innodb/fil_system_mutex 指出目前有一個以上的作業需要擷取和操控相同資料表空間之資料表空間記憶體快取中的資訊。

等待變多的可能原因

synch/mutex/innodb/fil_system_mutex 事件比平時更常出現時，可能表示有效能問題，這通常發生在下列所有情況都存在時：

  • 更新或刪除同一資料表中資料的並行資料處理語言 (DML) 作業增加。

  • 此資料表的資料表空間非常大，並有許多資料頁面。

  • 這些資料頁面的填滿係數很低。

動作

根據等待事件的原因，我們會建議不同的動作。

識別造成事件的工作階段和查詢

通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，請檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。

尋找負責高負載的 SQL 查詢

  1. 登入 AWS Management Console，並開啟 Amazon RDS 主控台，網址為 https://console.aws.amazon.com/rds/。

  2. 在導覽窗格中，選擇 Performance Insights (績效詳情)。

  3. 選擇資料庫執行個體。該資料庫執行個體的績效詳情儀表板即會出現。

  4. 在 Database load (資料庫負載) 圖表中，選擇 Slice by wait (依等待建立配量)。

  5. 在頁面底端，選擇 Top SQL (最高 SQL)。

    此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。

如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章利用績效詳情分析 Amazon Aurora MySQL 工作負載。

了解哪些查詢導致大量 synch/mutex/innodb/fil_system_mutex 等待的另一種方法是檢查 performance_schema，如下列範例所示。

mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
            THREAD_ID: 19
             EVENT_ID: 195057
         END_EVENT_ID: 195057
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:6700
          TIMER_START: 1010146190118400
            TIMER_END: 1010146196524000
           TIMER_WAIT: 6405600
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 2. row ***************************
            THREAD_ID: 23
             EVENT_ID: 5480
         END_EVENT_ID: 5480
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:5906
          TIMER_START: 995269979908800
            TIMER_END: 995269980159200
           TIMER_WAIT: 250400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 3. row ***************************
            THREAD_ID: 55
             EVENT_ID: 23233794
         END_EVENT_ID: NULL
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:449
          TIMER_START: 1010492125341600
            TIMER_END: 1010494304900000
           TIMER_WAIT: 2179558400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: 23233786
   NESTING_EVENT_TYPE: WAIT
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL

在離峰時間重組大型資料表

在生產時間以外的維護時段期間，重組您識別為大量 synch/mutex/innodb/fil_system_mutex 等待事件之來源的大型資料表。這樣做可確保內部資料表空間映射清除不會在快速存取資料表至關重要時發生。如需重組資料表的相關資訊，請參閱《MySQL 參考》中的 OPTIMIZE TABLE 陳述式。