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

# io/table/sql/handler
<a name="ams-waits.waitio"></a>

當工作已委派給儲存引擎時，`io/table/sql/handler` 事件便會發生。

**Topics**
+ [支援的引擎版本](#ams-waits.waitio.context.supported)
+ [Context](#ams-waits.waitio.context)
+ [等待時間增加的可能原因](#ams-waits.waitio.causes)
+ [動作](#ams-waits.waitio.actions)

## 支援的引擎版本
<a name="ams-waits.waitio.context.supported"></a>

下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版

## Context
<a name="ams-waits.waitio.context"></a>

事件 `io/table` 指出等待存取資料表。無論是在緩衝集區中快取資料，還是在磁碟上存取資料，都會發生此事件。`io/table/sql/handler` 事件表示工作負載活動增加。

「處理常式」**是專門處理特定類型的資料或專注於某些特殊任務的常式。例如，事件處理常式會接收和摘錄來自作業系統或使用者界面的事件和訊號。記憶體處理常式會執行與記憶體相關的任務。文件輸入處理常式是接收檔案輸入，並根據內容對資料執行特殊任務的函數。

當實際等待是巢狀等待事件 (例如鎖定) 時，`performance_schema.events_waits_current` 這類的檢視經常顯示 `io/table/sql/handler`。當實際的等待不是 `io/table/sql/handler` 時，績效詳情會報告巢狀等待事件。當 Performance Insights 報告 `io/table/sql/handler` 時，它代表 I/O 請求的 InnoDB 處理，而不是隱藏的巢狀等待事件。如需詳細資訊，請參閱 *MySQL 參考手冊*中的[效能結構描述原子和分子事件](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)。

`io/table/sql/handler` 事件通常會與 I/O 等待 (例如 `io/aurora_redo_log_flush`) 一起出現在最久等待事件中。

## 等待時間增加的可能原因
<a name="ams-waits.waitio.causes"></a>

在績效詳情中，`io/table/sql/handler` 事件中的突然峰值表示工作負載活動增加。活動增加意味著輸入/輸出增加。

績效詳情會篩選巢狀事件 ID，而且在基礎巢狀事件是鎖等待時不會報告 `io/table/sql/handler` 等待。例如，如果根本原因事件是 [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)，績效詳情會在最高等待事件中顯示此等待，而不是 `io/table/sql/handler`。

在 `performance_schema.events_waits_current` 這類的檢視中，當實際等待是巢狀等待事件 (例如鎖定) 時，`io/table/sql/handler` 的等待通常就會出現。當實際等待與 `io/table/sql/handler` 不同時，績效詳情會查閱巢狀等待，並報告實際等待，而不是 `io/table/sql/handler`。當績效詳情報告 `io/table/sql/handler` 時，真正的等待是 `io/table/sql/handler`，而不是隱藏的巢狀等待事件。如需詳細資訊，請參閱 *MySQL 5.7 參考手冊*中的[效能結構描述原子和分子事件](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)。

## 動作
<a name="ams-waits.waitio.actions"></a>

如果此等待事件主導資料庫活動，則不見得表示有效能問題。當資料庫作用中時，等待事件一律在頂端。只有在效能降低時才需要採取行動。

我們會建議不同的動作，取決於您看到的其他等待事件。

**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.waitio.actions.identify)
+ [檢查是否與績效詳情計數器指標關聯](#ams-waits.waitio.actions.filters)
+ [檢查是否有其他關聯的等待事件](#ams-waits.waitio.actions.maintenance)

### 識別造成事件的工作階段和查詢
<a name="ams-waits.waitio.actions.identify"></a>

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

**尋找負責高負載的 SQL 查詢**

1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。

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

1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。

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

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

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

如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。

### 檢查是否與績效詳情計數器指標關聯
<a name="ams-waits.waitio.actions.filters"></a>

檢查是否有績效詳情指標，例如 `Innodb_rows_changed`。如果計數器指標與 `io/table/sql/handler` 關聯，請遵循下列步驟：

1. 在績效詳情中，尋找說明 `io/table/sql/handler` 最高等待事件的 SQL 陳述式。如果可能，請最佳化此陳述式，以便其傳回較少的資料列。

1. 從 `schema_table_statistics` 和 `x$schema_table_statistics` 檢視中擷取最高資料表。這些檢視會顯示每個資料表所花費的時間量。如需詳細資訊，請參閱《MySQL 參考手冊》**中的 [schema\$1table\$1statistics 和 x\$1schema\$1table\$1statistics 檢視](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html)。

   根據預設，資料列會依總等待時間遞減排序。具有最多爭用的資料表會最先出現。輸出指示時間是花費在讀取、寫入、提取、插入、更新，還是刪除。

   ```
   mysql> select * from sys.schema_table_statistics limit 1\G
   
   *************************** 1. row ***************************
        table_schema: read_only_db
          table_name: sbtest41
       total_latency: 54.11 m
        rows_fetched: 6001557
       fetch_latency: 39.14 m
       rows_inserted: 14833
      insert_latency: 5.78 m
        rows_updated: 30470
      update_latency: 5.39 m
        rows_deleted: 14833
      delete_latency: 3.81 m
    io_read_requests: NULL
             io_read: NULL
     io_read_latency: NULL
   io_write_requests: NULL
            io_write: NULL
    io_write_latency: NULL
    io_misc_requests: NULL
     io_misc_latency: NULL
   1 row in set (0.11 sec)
   ```

### 檢查是否有其他關聯的等待事件
<a name="ams-waits.waitio.actions.maintenance"></a>

如果 `synch/sxlock/innodb/btr_search_latch` 和 `io/table/sql/handler` 是造成資料庫負載異常的主因，請檢查 `innodb_adaptive_hash_index` 變數是否已開啟。若是，請考慮增加 `innodb_adaptive_hash_index_parts` 參數值。

如果自適應雜湊索引已關閉，請考慮將其開啟。若要進一步了解 MySQL 自適應雜湊索引，請參閱下列資源：
+ Percona 網站上的文章 [InnoDB 中的自適應雜湊索引是否適合我的工作負載？](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload)
+ 《MySQL 參考手冊》**中的[自適應雜湊索引](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html)
+ Percona 網站上的文章 [MySQL InnoDB 中的爭用：來自旗號區段的有用資訊](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/)

**注意**  
Aurora 讀取器資料庫執行個體不支援自適應雜湊索引。  
在某些情況下，當 `synch/sxlock/innodb/btr_search_latch` 和 `io/table/sql/handler` 主導時，讀取器執行個體的效能可能不佳。若是這樣，請考慮將工作負載暫時重新導向至寫入器節點，並開啟自適應雜湊索引。