查詢引擎狀態中的 MySQL 信號量

在我們的一個從屬數據庫最近出現問題/減速期間，我注意到當我執行SHOW ENGINE INNODB STATUS. 我得到以下資訊：

----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 822986039, signal count 17045541908
--Thread 140562108442368 has waited at row0sel.c line 2930 for 0.00 seconds the semaphore:
S-lock on RW-latch at 0x7fd752e55c40 created in file buf0buf.c line 938
a writer (thread id 140562088974080) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0sel.c line 2930
Last time write locked in file /tmp/buildd/mysql-5.5-5.5.44/storage/innobase/buf/buf0buf.c line 3168

事實上，這種情況大約有 15 個。

查看交易，列出了 apx 200 筆交易，其中有一半顯示為waiting in InnoDB queue，另一半顯示為fetching data。

所有的交易都是SELECT查詢，它們都沒有顯示任何locks.

誰能告訴我SEMAPHORES（以上）與什麼有關？

信號量與等待作業系統中的內部執行緒鎖有關

您可以在Peter Zaitsev 的 SHOW INNODB STATUS walk through中找到一個很好的討論

在我看來，這與兩件事有關

• innodb_concurrency_tickets
• innodb_thread_concurrency

我的猜測是您將innodb_thread_concurrency設置為非零數。這會導致 InnoDB 儲存引擎限制其對內部執行緒的使用。因此，這將導致事務進入隊列。

早在 2011 年，我就寫過關於這個的文章

• Sep 12, 2011:可以讓 MySQL 使用多個核心嗎？
• Aug 16, 2011:為什麼禁用查詢記憶體時，MySQL 執行緒經常顯示“freeing items”狀態？
• May 26, 2011:關於單執行緒與多執行緒數據庫的性能

我在 2011 年去了 Percona Live NYC。Ronald Bradford 在一次研討會上告訴我將innodb_thread_concurrency保持為零（0）。為什麼 ？

正如我在 2011 年 8 月 16 日的文章中提到的：

他明確地告訴我，我永遠不應該針對 innodb_thread_concurrency 設置值。讓它始終為預設值，現在為零 (0)。通過這樣做，您可以讓 InnoDB 儲存自行決定要生成多少個 innodb_concurrency_ticket。這就是無限並發的作用。

如果您將innodb_thread_concurrency作為非零值，請將其設置為 0 或將其從my.cnf. 請注意，MySQL 5.6 允許 5000 個票證，而MySQL 5.5 僅允許 500 個票證。

如果要更改這些值，可以使用

SET GLOBAL innodb_thread_concurrency = 0;

我建議根本不要設置innodb_concurrency_tickets。

我還建議閱讀Pythian 的 ONCE AGAIN ABOUT INNODB-CONCURRENCY-TICKETS

引用自：https://dba.stackexchange.com/questions/123703