MySQL 5.7.19 版本出現(xiàn) Semaphore wait has lasted > 600 seconds 錯(cuò)誤，意味著 InnoDB 內(nèi)部某些線程等待信號(hào)量超過(guò)了10分鐘，導(dǎo)致數(shù)據(jù)庫(kù)掛起崩潰。

針對(duì)這個(gè)問(wèn)題，排查和定位的思路及步驟如下：

1. 理解信號(hào)量（Semaphore）和等待的背景

• InnoDB 通過(guò)信號(hào)量機(jī)制保護(hù)共享資源訪問(wèn)，例如緩沖池頁(yè)、鎖、事務(wù)信息等。
• 長(zhǎng)時(shí)間等待信號(hào)量一般是死鎖、資源競(jìng)爭(zhēng)、內(nèi)部異?；騃O瓶頸導(dǎo)致的。
• 錯(cuò)誤日志中會(huì)列出等待信號(hào)量的線程堆棧位置（源碼文件 + 行號(hào)），有助定位是哪類資源阻塞。

2. 收集環(huán)境與上下文信息

MySQL版本：

• 5.7.19，是較早的5.7版本，InnoDB還有一些已修復(fù)的問(wèn)題，建議考慮升級(jí)。

服務(wù)器硬件與資源狀況：

• CPU、內(nèi)存利用率
• 磁盤(pán)IO狀況（IOPS、延遲）

數(shù)據(jù)庫(kù)負(fù)載情況：

• 并發(fā)連接數(shù)
• 讀寫(xiě)比例
• 是否有長(zhǎng)事務(wù)/大事務(wù)

具體業(yè)務(wù)場(chǎng)景：

• 當(dāng)時(shí)運(yùn)行什么SQL，是否有大量INSERT/UPDATE/DELETE
• 是否有DDL操作（alter、drop）

3. 查看MySQL錯(cuò)誤日志和InnoDB狀態(tài)

a. 錯(cuò)誤日志中的關(guān)鍵信息

確認(rèn)報(bào)錯(cuò)線程對(duì)應(yīng)的源碼文件和行號(hào)：

mtr0mtr.cc，row0ins.cc 等，分別代表：

• mtr0mtr.cc：多版本事務(wù)相關(guān)管理（Mini-transaction）
• row0ins.cc：行插入相關(guān)代碼

這些提示可能表明在插入操作中出現(xiàn)了阻塞。

b. 通過(guò)SHOW ENGINE INNODB STATUS\G觀察

• 鎖等待情況（LATEST DETECTED DEADLOCK）
• 當(dāng)前活躍事務(wù)列表
• semaphore wait 信息（SEMAPHORE WAIT塊）
• 主線程或阻塞線程的詳細(xì)信息

4. 結(jié)合源碼行號(hào)，定位具體阻塞點(diǎn)

可以通過(guò)查看5.7.19版本源碼對(duì)應(yīng)文件（MySQL官方github或者源碼包）定位：

• mtr0mtr.cc line 567

涉及Mini-transaction相關(guān)鎖等待，可能是InnoDB內(nèi)部的metadata鎖或緩沖池訪問(wèn)競(jìng)爭(zhēng)。

• row0ins.cc line 193

插入行時(shí)等待信號(hào)量，可能是插入緩沖區(qū)競(jìng)爭(zhēng)或插入鎖等待。

5. 重點(diǎn)排查方向

5.1 長(zhǎng)事務(wù)導(dǎo)致鎖資源占用

• SHOW PROCESSLIST 看是否存在長(zhǎng)時(shí)間未提交的事務(wù)。
• INFORMATION_SCHEMA.INNODB_TRX 查看當(dāng)前活動(dòng)事務(wù)。
• 關(guān)閉長(zhǎng)事務(wù)或者合理設(shè)置事務(wù)超時(shí)。

5.2 高并發(fā)寫(xiě)入導(dǎo)致緩沖池爭(zhēng)用

高并發(fā)大批量寫(xiě)入，緩沖池頁(yè)鎖爭(zhēng)用嚴(yán)重。

調(diào)整 InnoDB 參數(shù)，如：

• innodb_thread_concurrency
• innodb_lock_wait_timeout
• innodb_buffer_pool_size (確保足夠大，避免頻繁刷盤(pán))

5.3 磁盤(pán)IO瓶頸

• 使用系統(tǒng)工具（iostat, vmstat）檢查磁盤(pán)負(fù)載和延遲。
• 高IO延遲會(huì)導(dǎo)致InnoDB鎖等待。

5.4 表空間或數(shù)據(jù)頁(yè)損壞

• 使用 CHECK TABLE 檢查相關(guān)表。
• 參考錯(cuò)誤日志是否有提示頁(yè)損壞。

6. 其他診斷技巧

6.1 啟用詳細(xì)InnoDB調(diào)試日志

啟動(dòng)MySQL時(shí)添加：

[mysqld]
innodb_print_all_deadlocks=ON
innodb_lock_wait_timeout=50

查看死鎖詳細(xì)信息。

6.2 使用性能Schema定位鎖等待

• 查詢 performance_schema.data_locks 和 performance_schema.data_lock_waits ，定位鎖資源。

7. 解決建議總結(jié)

8. 典型診斷命令舉例

-- 查看當(dāng)前阻塞事務(wù)
SELECT * FROM information_schema.innodb_trx\G;

-- 查看當(dāng)前等待鎖的線程
SELECT * FROM performance_schema.data_locks WHERE LOCK_STATUS='WAITING';

-- 查看進(jìn)程列表，看長(zhǎng)時(shí)間執(zhí)行的SQL
SHOW FULL PROCESSLIST;

-- 查看死鎖日志（在錯(cuò)誤日志中）
-- 或啟用 innodb_print_all_deadlocks=ON 后捕獲

總結(jié)

先從當(dāng)前活躍事務(wù)和鎖等待入手排查。

結(jié)合InnoDB狀態(tài)和系統(tǒng)IO性能分析瓶頸。

若懷疑數(shù)據(jù)損壞，嘗試使用 innodb_force_recovery。

5.7.19版本較老，建議升級(jí)至5.7較新版本，或者8.0版本，獲得更多穩(wěn)定性和bug修復(fù)。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。