synch/mutex/innodb/fil_system_mutex - Amazon Aurora
支持的引擎版本上下文等待次数增加的可能原因操作
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

synch/mutex/innodb/fil_system_mutex

当会话等待访问表空间内存缓存时，会发生 synch/mutex/innodb/fil_system_mutex 事件。

支持的引擎版本

以下引擎版本支持此等待事件信息：

  • Aurora MySQL 版本 2 和 3

上下文

InnoDB 使用表空间来管理表和日志文件的存储区域。表空间内存缓存是一种全局内存结构，用于维护有关表空间的信息。MySQL 使用 synch/mutex/innodb/fil_system_mutex 等待控制对表空间内存缓存的并发访问。

事件 synch/mutex/innodb/fil_system_mutex 表示当前有多个操作需要检索和操作同一表空间的表空间内存缓存中的信息。

等待次数增加的可能原因

当 synch/mutex/innodb/fil_system_mutex 事件的发生率超过正常（可能表示性能问题）时，该情况通常会在以下所有条件均存在时发生：

  • 更新或删除同一表中的数据的并发数据操作语言 (DML) 操作增加。

  • 此表的表空间非常大，有很多数据页面。

  • 这些数据页面的填充系数很低。

操作

根据等待事件的原因，我们建议采取不同的操作。

确定导致事件的会话和查询

通常，具有中等到大量负载的数据库都会有等待事件。如果性能最佳，等待事件可能是可以接受的。如果性能不佳，请检查数据库花费最多时间的位置。查看导致最高负载的等待事件，并了解是否可以优化数据库和应用程序以减少这些事件。

查找负责高负载的 SQL 查询

  1. 登录 Amazon Web Services 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 语句。