後面又做了補充測試，增加了每秒context switch的監控，以及SQL執行時各步驟消耗時間的監控。

【測試現象一】

啟用1000個併發執行緒的壓測程式，保持壓測程式持續執行，保持innodb_spin_wait_delay預設值不變

在10:17:14秒將innodb_spin_wait_delay值從預設值6調整為18，看到sys從40%降到20%

TPS從1.7W增加到2W

context switch從82W降到78W

【測試現象二】

開啟SQL執行時各步驟消耗時間的監控，重點關注stage/sql/update步驟的時間消耗(TIMER_WAIT的單位是picoseconds)，下面是截取了每個場景下執行接近平均時間的SQL過程取樣。

1、下圖是單句insert執行時情況，stage/sql/update時間約0.077豪秒

2、下圖是innodb_spin_wait_delay=6時，TPS約在1.7W時insert執行時情況，stage/sql/update時間約32毫秒

3、下圖是innodb_spin_wait_delay=18時，TPS約在2W時insert執行時情況，stage/sql/update時間約1.5毫秒

【測試結論】

1 、關於加大spin_wait_delay的理解，增大spin_wait_delay會讓執行緒在進入os wait之前再多spin一段時間，增加時間會增加獲取到rw-lock的概率，減少CPU空轉的次數，當spin wait的迴圈次數在1-30之間獲取到rw-lock時，則不會進入os wait，這種情況下減少了context switch的次數。從而減少了sys CPU的消耗，表現出來的現象是SQL執行時間變短，TPS處理能力上升。

2、innodb_spin_wait_delay的單位，是100MHZ的奔騰處理器處理1毫秒的時間，預設innodb_spin_wait_delay配置成6，表示最多在100MHZ的奔騰處理器上自旋6毫秒。

現在CPU是按照GHZ來計算的(測試是基於Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 40核的CPU處理器)，預設值相對變的很短，建議可以將這個配置值適當調大。

3、MySQL高併發寫入出現瓶頸，確實不像SQL Server的Latch等待型別那麼明顯。我們需要結合TPS、CPU、IO、執行程序等情況來綜合定位。