顯示引擎innodb狀態詳解
很多人讓我來闡述一下 SHOW INNODB STATUS 的輸出信息，了解SHOW INNODB STATUS都輸出了幾個什麽信息，並且我們能夠這些信息中獲取什麽資訊，得以提高MySQL性能。
首先，讓我們來了解一下SHOW INNODB STATUS輸出的基礎，它打印了很多關於InnoDB內部性能相關的計數器，統計，事務處理信息等。在mysql 5中，InnoDB的性能統計結果也在 SHOW STATUS 結果中顯示了。大部分和SHOW INNODB STATUS的其他信息相同，在舊版本中還沒有這個功能。
SHOW INNODB STATUS中的很多統計值都是每秒更新一次的，如果你打算利用這些統計值的話，那麽最好統計一段時間內的結果.InnoDB首先輸出以下信息：
1。===================================== 2.060717 3:07:56 INNODB MONITOR OUTPUT 3。===================================== 4.從最後44秒計算的第二個平均值
首先要確認這是至少統計了20-30秒的樣本數據。如果平均統計間隔是0或1秒，那麽結果就沒什麽意義了。
說實在的我不喜歡InnoDB提供的平均值，因為很難取得合理的平均間隔統計值，如果你是寫腳本來取得SHOW INNODB狀態結果的話，那麽最好取得全局的統計結果，然後取得平均值當然了，直接查看輸出的結果信息也是很有用的。
下一部分顯示了信號（信號量）相關信息：
1 .---------- 2.SEMAPHORES 3 .---------- 4.OS等待信息：預約計數13569，信號數11421 5 .--線程1152170336等待./../include/buf0buf.ic行630，信號量為0.00秒： 6.Mutex在0x2a957858b8創建文件buf0buf.c行517，鎖var 0 7.等待標誌0 等待結束 9 .--線程1147709792等待./../include/buf0buf.ic行630為0.00秒信號量： 10.Mutex在0x2a957858b8創建文件buf0buf.c行517，鎖var 0 等待標誌0 等待結束 13.Mutex旋轉等待5672442，輪3899888，操作系統等待4719 14.RW共享自轉5920，操作系統等待2918; RW-excl旋轉3463，操作系統等待3163
這部分可以分成2個部分。一部分是當前的等待，這部分只是包含了在高並發環境下的全部記錄，因此InnoDB會頻繁回退到系統等待。如果等待是通過自旋鎖來解決的話，那麽這些信息就就不會顯示了。
通過這部分信息，你就會知道系統負載的熱點在哪了。不過這需要了解一下源碼相關的知識 - 從上面的信息中就可以看出來是哪個源碼文件中的哪行（不同的版本結果可能不同），只是從這裏卻看不出來任何信息。盡管如此，還是可以從文件名中猜到一些東西 - 比如本例中文，文件名“buf0buf.ic”預示著和一些緩沖池爭奪有關系如果想了解更多，就去看源碼吧。
還有一些關於等待的更多細節。“lock var”表示當前的mutex對象的值（被鎖住= 1 /釋放= 0）值，“waiters flag”表示當前的等待個數。另外，本例中還可以看到等待狀態信息“等待結束”，這表示mutex已經釋放，但是系統調度線程還正在處理。
第二塊是事件統計 - “預約計數”和“信號計數”顯示了innodb使用內部同步陣列的活躍程度 - 時間片（槽）分配以及線程信號使用同步陣列的頻繁程度這些統計信息可以用於表示innodb回退系統等待的頻率。還有關於系統等待的直接相關信息，可以看到“OS Waits”的互斥信號燈（mutexes），以及讀寫鎖這些信息中顯示了互斥鎖和共享鎖系統等待和“保留（保留）”不完全一樣，在回退到用sync_array的復雜等待模式前，innodb會嘗試“輸出（yield）”到系統，希望下一次調度時間對象裏命名線程已經釋放了。系統等待相對較慢，如果每秒發生了上萬次系統等待，則可能會有問題。另一個觀察方法是查看系統狀態中的上下文（上下文）交換頻率。
另一塊重要的信息是“旋轉等待”和“旋轉圓”的數量。相比於系統等待，自旋鎖是低成本的等待;不過它是一個活躍的等待，會浪費一些cpu資源。因此如果看到大量的自旋等待和自旋輪轉，則很顯然它浪費了很多CPU資源。浪費CPU時間和無謂的上下文切換之間可以 用innodb_sync_spin_loops 來平衡。
接下來的這段顯示死鎖狀況：
1 .------------------------ 最新檢測的死鎖 3 .------------------------ 4.060717 4:16:48 5。***（1）交易： 6.TRANSACTION 0 42313619，ACTIVE 49秒，進程號10099，OS線程號3771312開始索引讀取 7.mysql表中使用1，鎖定1 鎖定等待3鎖結構，堆大小320 9.MySQL線程號為30898，查詢id為100626 localhost root更新 10.update iz set pad =‘a‘其中i = 2 11。***（1）等待這個鎖定被授予： 12.RECORD LOCKS空格id 0頁否16403 n位72索引`PRIMARY‘表‘test / iz` trx id 0 42313619 lock_mode X鎖定rec但不等待間隙 記錄鎖，堆沒有5物理記錄：n_fields 4; 緊湊格式; 信息位0 0：len 4; 十六進制80000002; ; 1：len 6; 十六進制00000285a78f; ; 2：len 7; 十六進制00000040150110; asc @ ;; 3：len 10; hex 61202020202020202020; ; 15。 16。***（2）交易： 17.TRANSACTION 0 42313620，ACTIVE 24秒，進程號10099，OS線程號4078512起始索引讀取，線程聲明內部InnoDB 500 18.mysql表正在使用1，鎖定1 19.3鎖結構，堆大小320 20.MySQL線程號30899，查詢id 100627 localhost root更新 21.update iz set pad =‘a‘其中i = 1 22。***（2）DS THE：：：：：：：：：： 23.RECORD LOCKS空格id 0頁否16403 n位72索引`PRIMARY‘表‘test / iz` trx id 0 42313620 lock_mode X鎖定rec但不是間隙 24.記錄鎖，堆不5物理記錄：n_fields 4; 緊湊格式; 信息位0 0：len 4; 十六進制80000002; ; 1：len 6; 十六進制00000285a78f; ; 2：len 7; 十六進制00000040150110; asc @ ;; 3：len 10; hex 61202020202020202020; ; 26。 27。***（2）等待這個鎖定被授予： 28.RECORD LOCKS空格id 0頁號16403 n位72索引`PRIMARY‘表‘test / iz` trx id 0 42313620 lock_mode X鎖定rec但沒有間隙等待 記錄鎖，堆沒有4物理記錄：n_fields 4; 緊湊格式; 信息位0 0：len 4; hex 80000001; ; 1：len 6; 十六進制00000285a78e; ; 2：len 7; 十六進制000000003411d9; asc 4 ;; 3：len 10; hex 61202020202020202020; ; 31。 32。***我們回滾交易（2）
這裏顯示了Innodb最後檢測到事務引發的死鎖，包括發生死鎖時的狀態，加了什麽鎖，在等待什麽鎖釋放，以及Innodb決定哪個事務會被回滾。註意，innodb只顯示了事務持有鎖的相關簡單信息。並且只顯示了每個事務最後執行的語句，發生死鎖的記錄就是由於這些語句引起的。查看復雜的死鎖信息還需要查看日誌文件，才能找到真正引發沖突的語句大部分情況下，SHOW INNODB狀態顯示的信息基本足夠了。
下面是關於外鍵約束引發的死鎖信息：
1 .------------------------ 2.最新的外來鍵錯誤 3 .------------------------ 4.060717 4:29:00交易： 5.TRANSACTION 0 336342767，ACTIVE 0秒，進程號3946，OS線程號1151088992插入，在InnoDB 500中聲明的線程 使用mysql表1，鎖定1 7.3鎖結構，堆大小368，撤銷日誌條目1 8.MySQL線程號9697561，查詢id 188161264 localhost根更新 9.插入子值（2,2） 表‘test / child`的外鍵鍵約束失敗： 11， 12. CONSTRAINT`child_ibfk_1` FOREIGN KEY（`parent_id`）REFERENCES`parent`（`id`）ON DELETE CASCADE 13.嘗試在子表中添加索引中的`par_ind`元組： DATA TUPLE：2場; 0：len 4; 十六進制80000002; ; 1：len 6; 十六進制000000000401; ; 16。 在父表“test / parent”中，在索引“PRIMARY”中， 我們可以找到最接近的比賽是記錄： 物理記錄：n_fields 3; 1字節關閉TRUE; 信息位0 0：len 4; hex 80000001; ; 1：len 6; 十六進制0000140c2d8f; asc - ;; 2：len 7; 十六進制80009c40050084; asc @ ;;
Innodb的會顯示引發錯誤的語句。外鍵約束定義失敗，以及定義關系最密切的父表。有很多嵌接信息都是用16進制表示，不過對於問題診斷並不是太重要，它們主要用於給Innodb的開發者來查看或者用於調試目的。
接下來是顯示Innodb當前活躍的事務：
1 .------------ 2.TRANSACTIONS 3 .------------ 4.Trx id計數器0 80157601 5.對於trx的n進行完成：o <0 80154573 undo n：o <0 0 歷史名單長度6 行鎖哈希表中的鎖結構總數0 8.每屆會議交易清單： 9 .--- TRANSACTION 0 0，未啟動，進程號3396，OS線程號1152440672 10.MySQL線程號為8080，查詢id為728900 localhost根 顯示innodb狀態 12 .--- TRANSACTION 0 80157600，ACTIVE 4秒，進程號3396，OS線程號1148250464，InnoDB 442內部聲明的線程 13.mysql表正在使用1，鎖定0 14.MySQL線程號8079，查詢id 728899 localhost root發送數據 15.從b限制中選擇sql_calc_found_rows * 5 16.Trx讀取視圖不會看到id為= 80157601的trx，看到<0 80157597 17 .--- TRANSACTION 0 80157599，ACTIVE 5秒，進程號3396，操作系統線程號1150142816提取行，線程內宣告InnoDB 166 18.mysql表中使用1，鎖定0 19.MySQL線程id為8078，查詢id為728898 localhost root發送數據 20.從b限制中選擇sql_calc_found_rows * 5 21.Trx讀取視圖不會看到具有id> = 0的trx 80157600，看到<0 80157596 22 .--- TRANSACTION 0 80157598，ACTIVE 7秒，進程號3396，OS線程號1147980128提取行，線程在InnoDB 114內部聲明 23.mysql表正在使用1，鎖定0 24.MySQL線程id 8077，查詢id 728897 localhost root發送數據 25.從b限制中選擇sql_calc_found_rows * 5 26.Trx讀取視圖不會看到具有id> = 0的trx 80157599，看到<0 80157595 27 .--- TRANSACTION 0 80157597，ACTIVE 7秒，進程號3396，OS線程號1152305504提取行，線程內部聲明InnoDB 400 28. mysql表正在使用1，鎖定0 29.MySQL線程號8076，查詢id 728896 localhost root發送數據 30.從b限制中選擇sql_calc_found_rows * 5 31.Trx讀取視圖不會看到具有id> = 0的字符串0x157598，看到<0 80157594
如果當前連接不是很多，則會顯示全部事務列表;如果有大量連接，則Innodb只會顯示他們的數量，減少輸出的列表信息，使得輸出結果不會太多。
事務ID是當前事務的標識，事務的id每次都會增加。為trx的n清除完成：o 是指凈化（purge）線程已經完成的事務數.Innodb只清除那些被當前事務認為不再需要的舊版本數據。那些未提交的舊事務可能會阻塞凈化線程並且消耗資源。通過查看2次清除事務數之差，就可以知道是否發生了這種情況。少數情況下，凈化線程可能難以跟上更新的速度，2次查看值之差可能會越來越大;那麽，innodb_max_purge_lag 就派得上用場了。 “undo n：o” 顯示了凈化線程當前正在處理的回滾日誌號，如果當前不處於活躍狀態，那它的值是0。
歷史列表長度6 是指在回滾空間中的未清除事務數。隨著事務的提交，它的值會增加;隨著清除線程的運行，它的值會減小。
行鎖哈希表中 的鎖結構總數是指事務分配過的行鎖結構總數。它和曾經被鎖住過的行總數不一定相等，通常是一個鎖結構對應多行記錄。
MySQL中，每個連接如果沒有活動的事務，則它的狀態是 不啟動，如果有活動的事務，則是 ACTIVE。註意，盡管事務是活動的，但是其連接的狀態卻可能是“睡眠）“ - 如果是在一個有多條語句的事務裏的話.Innodb會同時顯示系統的線程號以及進程號，這有助於利用gdb來調試或者其他類似用途。另外，事務的狀態也會根據當前實際狀態來顯示，例如 “讀取記錄（提取行）”，em>“更新（更新）”等等。“InnoDB 400內的線程” 的意思是Innodb內核正在運行該線程，並且還需要400個票.Innodb會根據 innodb_thread_concurrency參數 的值來限制同時並發的線程數不超過它。如果線程當前不在Innodb的的內核中運行，則它的狀態可能是 “InnoDB的隊列中等待” 或 “加入隊列的InnoDB睡覺前”。這個可能的會導致Innodb內核中當前活躍的線程數可能比innodb_thread_concurrency 的值還小。某種負載環境下，這可能有助於減小線程進入隊列的時間。可以通過調整innodb_thread_sleep_delay 來實現，它的單位是微妙。
mysql表在使用1，locked 0 是指事務中已經用過的數據表個數（已經訪問過了的），以及被鎖的個數.Innodb一般情況不會鎖表，因此鎖表數一般是0 ，除非是 ALTER TABLE 或者其他類似 LOCK TABLES 的語句。
除了Innodb相關的特定信息外，一些基本信息可以通過來查看，例如正在執行什麽語句，查詢ID號，查詢狀態等。
下面這部分顯示的是跟IO相關的具體信息：
1 .-------- 2.FILE I / O 3 .-------- 4.I / O線程0狀態：等待i / o請求（插入緩沖線程） 5.I / O線程1狀態：等待i / o請求（日誌線程） 6.I / O線程2狀態：等待i / o請求（讀線程） 7.I / O線程3狀態：等待i / o請求（寫線程） 正常aio讀取：0，aio寫：0， ibuf aio讀取：0，log i / o‘s：0，sync i / o‘s：0 正常刷新（fsync）log：0; 緩沖池：0 11.17909940操作系統文件讀取，22088963操作系統文件寫入，1743764操作系統fsyncs 12.0.20讀/秒，16384平均字節/讀，5.00寫/秒，0.80 fsyncs / s
本部分顯示了IO助手線程狀態 - 插入緩沖線程，日誌線程，讀，寫線程。它們分別對應插入緩沖合並，異步日誌刷新，預讀以及刷新臟數據。源自查詢的正常讀取是由正在運行的查詢執行的。在Unix / Linux平臺下，總能看見4個線程，在Windows上可以通過 innodb_file_io_threads 來調整。每個線程準備好之後都能看到其狀態：等待i / o請求 或者正在執行特定的操作。
每個線程都會顯示正在進行的操作數量 - 同時正要執行或者正在執行的操作數量。另外，正在執行的fsync操作數量也會顯示出來。有寫數據時，Innodb需要確保數據最終被寫到磁盤上，只是把它們放在系統緩存裏是不夠的。通常是調用fsync（）來完成的。如果它的值一直很高，那意味這Innodb可能是處理IO負載較高狀態。註意，由線程執行請求引發的IO請求是不計算在內的，因此盡管系統的IO負載較高，但是它們的值卻可能為0。
接下來顯示的是IO操作的平均統計值，它們對於圖形顯示或者監控很有用。
“16384 avg bytes / read” 是讀請求的平均值。隨機IO的話，每個頁的大小是16K，全表掃描或索引掃描時的預讀會導致這個值明顯的增加。因此，它體現了預讀的效率。
1 .------------------------------------- 2.安全緩沖區和自適應哈希指數 3 .------------------------------------- 空間空間0：大小1，免費列表len 887，段大小889，不為空 5.Ibuf for space 0：size 1，free list len 887，seg size 889， 6.2431891插入，2672643合並記錄，1059730合並 7.表格大小為8850487，使用單元格2381348，節點堆有4091個緩沖區 8.2208.17哈希搜索/ s，175.05非哈希搜索/ s
本部分顯示了插入緩沖以及自適應哈希索引的狀態。第一行顯示了插入緩沖的狀態 - 段的大小以及空閑列表，以及緩沖中有多少記錄。接下來顯示了緩沖中已經完成了多少次插入，有多少記錄已經合並，有多少次合並已經完成，合並次數除以插入次數得到的比率可以反映出插入緩沖的效率如何。
Innodb采用哈希索引建立內存頁索引形成自適應哈希索引而不是采B-tree索引，得以加速行記錄到內存頁的檢索。這裏顯示了哈希表的大小，以及自適應哈希索引使用了多少單元和緩沖。可以通過計算利用哈希索引檢索的次數以及沒利用它檢索的次數來了解哈希索引的效率。
當前對自適應哈希索引基本沒有什麽辦法可以調整它，主要還是用於查看。
1 .--- 2.登錄 3 .--- 4.序號84 3000620880 5.記錄刷新到84 3000611265 最後檢查點為84 2939889199 7.0等待日誌寫入，0等待chkp寫入 8.14073669 log i / o的完成，10.90 log i / o的/秒
接下來顯示的是Innodb的日誌子系統相關信息。可以看到當前的日誌序列號 - 相當於Innodb自從表空間開始創建直到現在已經寫入日誌文件的總字節數。還可以看到日誌已經刷新到哪個點，同樣也可以根據最後檢查點計算出還有多少日誌沒有刷新到文件中去.Innodb采用模糊檢查點，因此這行顯示的是已經從緩沖池中刷新到文件的日誌序列號。由於更高的日誌序列號可能不會被立刻刷新到日誌文件中去，因此日誌序列號不能被覆蓋掉。通過監控刷新到哪個日誌的日誌序列，可以判定innodb_log_buffer_size 的設置是否合理，如果看到超過30 ％的日誌還沒有刷新到日誌文件中，則需要考慮增加它的值了。
另外，還能看到日誌寫入以及檢查點的數目。根據日誌I / O操作的數據可以區分開空間相關的IO請求和日誌IO請求數量，進而可以確定到底需要幾個日誌文件。innodb_flush_log_at_trx_commit 的值可以影響到日誌寫操作的代價高或低如果innodb_flush_logs_at_trx_commit = 2，則日誌是寫到系統緩存，然後再順序寫到日誌文件中，因此相對會快很多。
1 .---------------------- 2.緩沖池和存儲器 3 .---------------------- 總內存分配4648979546; 在附加池中分配16773888 緩沖池大小262144 免費緩沖區0 數據庫頁面258053 8.修改數據庫頁37491 9.待定閱讀0 10.待寫：LRU 0，刷新列表0，單頁0 11頁閱讀57973114，創建於251137，編號10761167 12.9.79讀/ s，0.31創建/秒，6.00寫/秒 緩沖池命中率999/1000
這部分顯示了緩沖池和內存的利用率相關信息。可以看到Innodb的分配的所有內存（有些時候可能比你設置的還要多點），以及額外的內存池分配情況（可以檢查它的大小是否正好），緩沖池總共有多少個內存頁，有多少空閑內存頁，數據庫分配了多少個內存頁以及有多少個臟內存頁。從這些信息中，就可以判斷內存緩沖池是否設定合理，如果總是有大量空閑內存頁，則不需要設置那麽多內存，可以適當減小一點。如果空閑內存頁為0，這種情況下數據庫內存頁就不一定會和緩沖池的總數一致，因為緩沖池還需要保存鎖信息，自適應哈希索引以及其他系統結構等信息。
等待中的讀寫是指內存緩沖池級別的請求.Innodb可能會把多個文件級別的請求合並到一個上，因此各不相同。我們還可以看到Innodb的提交的各種不同類型的IO，LRU內存頁中需要刷新頁面 - 臟內存頁，它們不會被長時間存取;刷新列表 -
檢查點進程處理完後需要刷新的舊內存頁;獨立內存頁 - 獨立的寫內存頁。
我們還可以看到內存頁總共讀寫了多少次。已經創建的內存頁是當前一個內存頁中的內容沒有讀取到內存緩沖池中時，專門為新數據創建的空內存頁。
最後我們可以看到緩沖池的命中率，它預示著緩沖池的效率.1000 / 1000相當於100％的命中率。不過這樣也很難說明緩沖池的命中率就足夠高了，這要需要根據不同的負載環境而定。通常情況下，950/1000就夠了，有些時候在IO負載較高的環境下，命中率可能為995/1000。
1 .-------------- 2.操作操作 3 .-------------- InnoDB中的4.0查詢，隊列中的0個查詢 5.1閱讀在InnoDB內開放的視圖 主線程過程號 10099，id 88021936，狀態：等待服務器活動 7.插入行數143，更新3000041，刪除0，讀取24865563 8.0.00插入/秒，0.00更新/秒，0.00刪除/秒，0.00讀/秒
最後一部分，顯示了數據行操作以及一些系統信息相關情況。
一開始顯示了Innodb線程隊列狀態 - 有多少線程處於等待或活躍的.Innodb內部打開了多少讀視圖 -
這是在事務開始後，但是當前還沒有活躍語句的情況時，InnoDB主線程的狀態控制了系統操作調度的數量-刷新臟內存頁，檢查點，凈化線程，刷新日誌，合並插入緩沖等 “狀態“ 的值則表示了主線程當前的狀態。
接下來可以看到自從系統啟動以來，所有的數據行操作數量及其平均值。它們可以很方便地用於監控以及畫出系統狀態圖，數據行操作次數可以很好的衡量Innodb的的負載。不是所有的數據行操作帶來的負載都是一樣的，存取10字節的行比的10Mb的行相比會小了很多，不過相對於查詢的總次數來說這個信息可是有用的多了，差別也很大。
還有一點需要註意的是，SHOW INNODB STATUS不是一成不變的，有些時間點上可能會不相符。是由於設計時需要由全局鎖提供一致性信息，導致了大量的開銷。
顯示引擎innodb狀態詳解