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

# synch/sxlock/innodb/hash\_table\_locks
<a name="ams-waits.sx-lock-hash-table-locks"></a>

當緩衝集區中找不到的頁面必須從儲存體讀取時，`synch/sxlock/innodb/hash_table_locks` 事件便會發生。

**Topics**
+ [支援的引擎版本](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Context](#ams-waits.sx-lock-hash-table-locks.context)
+ [等待變多的可能原因](#ams-waits.sx-lock-hash-table-locks.causes)
+ [動作](#ams-waits.sx-lock-hash-table-locks.actions)

## 支援的引擎版本
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

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

## Context
<a name="ams-waits.sx-lock-hash-table-locks.context"></a>

事件 `synch/sxlock/innodb/hash_table_locks` 指出工作負載經常存取未存放在緩衝集區中的資料。此等待事件與新的頁面新增相關，而且舊資料會從緩衝集區移出。存放在緩衝集區的資料過時，而且新資料必須進行快取，因此會將過時頁面移出，以允許快取新頁面。MySQL 會使用最近最少使用 (LRU) 演算法，從緩衝集區移出頁面。工作負載嘗試存取尚未載入至緩衝集區的資料或已從緩衝集區移出的資料。

當工作負載必須存取磁碟上檔案中的資料，或從緩衝集區的 LRU 清單釋放區塊，或將區塊新增至其中時，此等待事件便會發生。這些作業等待取得共用的排除鎖定 (SX-lock)。此 SX-lock 用於透過「雜湊表」**進行同步，此雜湊表是記憶體中的資料表，旨在改善緩衝集區存取效能。

如需詳細資訊，請參閱 MySQL 文件中的[緩衝集區](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html)。

## 等待變多的可能原因
<a name="ams-waits.sx-lock-hash-table-locks.causes"></a>

`synch/sxlock/innodb/hash_table_locks` 等待事件比平時更常出現時，可能表示有效能問題，典型原因包括：

**緩衝集區大小過小**  
緩衝集區的大小太小，無法將所有經常存取的頁面保留在記憶體中。

**工作負載繁重**  
工作負載導致頻繁的移出，並在緩衝區快取中重新載入資料頁面。

**讀取頁面時發生錯誤**  
讀取緩衝集區中的頁面時發生錯誤，這可能表示資料損毀。

## 動作
<a name="ams-waits.sx-lock-hash-table-locks.actions"></a>

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

**Topics**
+ [增加緩衝集區的大小](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [改善資料存取模式](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [減少或避免完整資料表掃描](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [檢查錯誤日誌是否有頁面毀損](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)

### 增加緩衝集區的大小
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

確定緩衝集區已適當地調整為適合工作負載的大小。若要這樣做，您可以檢查緩衝區快取命中率。通常，如果值低於 95%，請考慮增加緩衝集區大小。越大的緩衝集區可以將經常存取的頁面保留在記憶體中的時間越長 若要增加緩衝集區的大小，請修改 `innodb_buffer_pool_size` 參數的值。此參數的預設值是基於資料庫執行個體類別大小。如需詳細資訊，請參閱 [Amazon Aurora MySQL 資料庫組態的最佳實務](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)。

### 改善資料存取模式
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

檢查受此等待及其執行計劃影響的查詢。考慮改善資料存取模式。例如，如果您是使用 [mysqli\_result::fetch\_array](https://www.php.net/manual/en/mysqli-result.fetch-array.php)，則可以嘗試增加陣列擷取大小。

您可以使用績效詳情來顯示可能造成 `synch/sxlock/innodb/hash_table_locks` 等待事件的查詢和工作階段。

**尋找負責高負載的 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 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。

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

### 減少或避免完整資料表掃描
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

監控工作負載，以查看它是否正在執行完整資料表掃描，若是，請減少或避免它們。例如，您可以監控狀態變數，例如 `Handler_read_rnd_next`。如需詳細資訊，請參閱 MySQL 文件中的[伺服器狀態變數](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next)。

### 檢查錯誤日誌是否有頁面毀損
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

你可以檢查 mysql-error.log，是否在接近問題發生時偵測到毀損相關訊息。您可以用來解決問題的訊息位於錯誤日誌中。您可能需要重新建立已報告為毀損的物件。