本篇內(nèi)容介紹了“MySQL中的SHOW ENGINE INNODB STATUS舉例分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站制作、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、密山ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的密山網(wǎng)站制作公司

首先，讓我們來(lái)了解一下 SHOW ENGINE INNODB STATUS 輸出的基礎(chǔ)，它打印了很多關(guān)于 InnoDB  內(nèi)部性能相關(guān)的計(jì)數(shù)器、統(tǒng)計(jì)、事務(wù)處理信息等。在 MySQL 5 中，InnoDB 的性能統(tǒng)計(jì)結(jié)果也在 SHOW STATUS 結(jié)果中顯示了。大部分和 SHOW ENGINE INNODB STATUS 的其他信息相同，在舊版本中還沒(méi)有這個(gè)功能。

SHOW ENGINE INNODB  STATUS  中的很多統(tǒng)計(jì)值都是每秒更新一次的，如果你打算利用這些統(tǒng)計(jì)值的話，那么最好統(tǒng)計(jì)一段時(shí)間內(nèi)的結(jié)果。InnoDB 首先輸出以下信息：

1.=====================================
2.060717  3:07:56 INNODB MONITOR OUTPUT
3.=====================================
4.Per second averages calculated from the last 44 seconds

首先要確認(rèn)這是至少統(tǒng)計(jì)了 20-30 秒的樣本數(shù)據(jù)。如果平均統(tǒng)計(jì)間隔是0或1秒，那么結(jié)果就沒(méi)什么意義了。
 InnoDB提供的平均值，很難取得合理的平均間隔統(tǒng)計(jì)值，如果你是寫(xiě)腳本來(lái)取得 SHOW ENGINE INNODB STATUS  結(jié)果的話，那么最好取得全局的統(tǒng)計(jì)結(jié)果，然后取得平均值。當(dāng)然了，直接查看輸出的結(jié)果信息也是很有用的。

下一部分顯示了信號(hào)(Semaphores)相關(guān)信息：

1.----------
2.SEMAPHORES
3.----------
4.OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
5.--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
6.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
7.waiters flag 0
8.wait is ending
9.--Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
10.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
11.waiters flag 0
12.wait is ending
13.Mutex spin waits 5672442, rounds 3899888, OS waits 4719
14.RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163

這段可以分成2個(gè)部分。一部分是當(dāng)前的等待，這部分只是包含了在高并發(fā)環(huán)境下的全部記錄，因此 InnoDB  會(huì)頻繁回退到系統(tǒng)等待。如果等待是通過(guò)自旋鎖來(lái)解決的話，那么這些信息就就不會(huì)顯示了。

通過(guò)這部分信息，你就會(huì)知道系統(tǒng)負(fù)載的熱點(diǎn)在哪了。不過(guò)這需要了解一下源碼相關(guān)的知識(shí) -  從上面的信息中就可以看出來(lái)是哪個(gè)源碼文件中的哪行(不同的版本結(jié)果可能不同)，只是從這里卻看不出來(lái)任何信息。盡管如此，還是可以從文件名中猜到一些東 西 - 比如本例中，文件名 "buf0buf.ic" 預(yù)示著和一些緩沖池爭(zhēng)奪有關(guān)系。如果想了解更多，就去看源碼吧。

還有一些關(guān)于等待的更多細(xì)節(jié)。"lock var" 表示當(dāng)前的 mutex 對(duì)象的值(被鎖住 = 1 / 釋放 = 0)  值，"waiters flag" 表示當(dāng)前的等待個(gè)數(shù)。另外，本例中還可以看到等待狀態(tài)信息 "wait is ending"，這表示 mutex  已經(jīng)釋放，但是系統(tǒng)調(diào)度線程還正在處理。

第二塊是事件統(tǒng)計(jì) - "reservation count" 和 "signal count" 顯示了 innodb  使用內(nèi)部同步陣列的活躍程度 - 時(shí)間片(slot)分配以及線程信號(hào)使用同步陣列的頻繁程度。這些統(tǒng)計(jì)信息可以用于表示 innodb  回退到系統(tǒng)等待的頻率。還有關(guān)于系統(tǒng)等待的直接相關(guān)信息，可以看到"OS  Waits"的互斥信號(hào)燈(mutexes)，以及讀寫(xiě)鎖。這些信息中顯示了互斥鎖和共享鎖。系統(tǒng)等待和 "保留(reservation)"  不完全一樣，在回退到用 sync_array 的復(fù)雜等待模式前，innodb 會(huì)嘗試 "輸出(yield)"  到系統(tǒng)，希望下一次調(diào)度時(shí)間對(duì)象里命名線程已經(jīng)釋放了。系統(tǒng)等待相對(duì)較慢，如果每秒發(fā)生了上萬(wàn)次系統(tǒng)等待，則可能會(huì)有問(wèn)題。另一個(gè)觀察方法是查看系統(tǒng)狀態(tài) 中的上下文(context)交換頻率。

另一塊重要的信息是 "spin waits" 和 "spin rounds"  的數(shù)量。相較于系統(tǒng)等待，自旋鎖是低成本的等待；不過(guò)它是一個(gè)活躍的等待，會(huì)浪費(fèi)一些cpu資源。因此如果看到大量的自旋等待和自旋輪轉(zhuǎn)，則很顯然它浪費(fèi) 了很多cpu資源。浪費(fèi)cpu時(shí)間和無(wú)謂的上下文切換之間可以用 innodb_sync_spin_loops  來(lái)平衡。

接下來(lái)的這段顯示死鎖狀況:

1.------------------------
2.LATEST DETECTED DEADLOCK
3.------------------------
4.060717  4:16:48
5.*** (1) TRANSACTION:
6.TRANSACTION 0 42313619, ACTIVE 49 sec, process no 10099, OS thread id 3771312 starting index read
7.mysql tables in use 1, locked 1
8.LOCK WAIT 3 lock struct(s), heap size 320
9.MySQL thread id 30898, query id 100626 localhost root Updating
10.update iz set pad='a' where i=2
11.*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
12.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313619 lock_mode X locks rec but not gap waiting
13.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
14. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
15. 
16.*** (2) TRANSACTION:
17.TRANSACTION 0 42313620, ACTIVE 24 sec, process no 10099, OS thread id 4078512 starting index read, thread declared inside InnoDB 500
18.mysql tables in use 1, locked 1
19.3 lock struct(s), heap size 320
20.MySQL thread id 30899, query id 100627 localhost root Updating
21.update iz set pad='a' where i=1
22.*** (2) HOLDS THE LOCK(S):
23.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap
24.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
25. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
26. 
27.*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
28.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap waiting
29.Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
30. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 00000285a78e; asc       ;; 2: len 7; hex 000000003411d9; asc     4  ;; 3: len 10; hex 61202020202020202020; asc a         ;;
31. 
32.*** WE ROLL BACK TRANSACTION (2)

這里顯示了 Innodb 最后檢測(cè)到事務(wù)引發(fā)的死鎖，包括發(fā)生死鎖時(shí)的狀態(tài)，加了什么鎖，在等待什么鎖釋放，以及 Innodb  決定哪個(gè)事務(wù)會(huì)被回滾。注意，innodb只顯示了事務(wù)持有鎖的相關(guān)簡(jiǎn)單信息。并且只顯示了每個(gè)事務(wù)最后執(zhí)行的語(yǔ)句，發(fā)生死鎖的記錄就是由于這些語(yǔ)句引起 的。查看復(fù)雜的死鎖信息還需要查看日志文件，才能找到真正引發(fā)沖突的語(yǔ)句。大部分情況下，SHOW INNODB STATUS 顯示的信息基本足夠了。

下面是關(guān)于外鍵約束引發(fā)的死鎖信息：

1.------------------------
2.LATEST FOREIGN KEY ERROR
3.------------------------
4.060717  4:29:00 Transaction:
5.TRANSACTION 0 336342767, ACTIVE 0 sec, process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 500
6.mysql tables in use 1, locked 1
7.3 lock struct(s), heap size 368, undo log entries 1
8.MySQL thread id 9697561, query id 188161264 localhost root update
9.insert into child values(2,2)
10.Foreign key constraint fails for table `test/child`:
11.,
12.  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE
13.Trying to add in child table, in index `par_ind` tuple:
14.DATA TUPLE: 2 fields;
15. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 000000000401; asc       ;;
16. 
17.But in parent table `test/parent`, in index `PRIMARY`,
18.the closest match we can find is record:
19.PHYSICAL RECORD: n_fields 3; 1-byte offs TRUE; info bits 0
20. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000140c2d8f; asc     - ;; 2: len 7; hex 80009c40050084; asc    @   ;;

Innodb會(huì)顯示引發(fā)錯(cuò)誤的語(yǔ)句。外鍵約束定義失敗，以及定義關(guān)系最密切的父表。有很多嵌接信息都是用16進(jìn)制表示，不過(guò)對(duì)于問(wèn)題診斷并不是太重 要，它們主要用于給 Innodb 的開(kāi)發(fā)者來(lái)查看或者用于調(diào)試目的。

接下來(lái)是顯示 Innodb 當(dāng)前活躍的事務(wù)：

1.------------
2.TRANSACTIONS
3.------------
4.Trx id counter 0 80157601
5.Purge done for trx's n:o <0 80154573 undo n:o <0 0
6.History list length 6
7.Total number of lock structs in row lock hash table 0
8.LIST OF TRANSACTIONS FOR EACH SESSION:
9.---TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672
10.MySQL thread id 8080, query id 728900 localhost root
11.show innodb status
12.---TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
13.mysql tables in use 1, locked 0
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.select sql_calc_found_rows  * from b limit 5
16.Trx read view will not see trx with id>= 0 80157601, sees <0 80157597
17.---TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
18.mysql tables in use 1, locked 0
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.select sql_calc_found_rows  * from b limit 5
21.Trx read view will not see trx with id>= 0 80157600, sees <0 80157596
22.---TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
23.mysql tables in use 1, locked 0
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.select sql_calc_found_rows  * from b limit 5
26.Trx read view will not see trx with id>= 0 80157599, sees <0 80157595
27.---TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
28.mysql tables in use 1, locked 0
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.select sql_calc_found_rows  * from b limit 5
31.Trx read view will not see trx with id>= 0 80157598, sees <0 80157594

如果當(dāng)前連接不是很多，則會(huì)顯示全部事務(wù)列表；如果有大量連接，則 Innodb  只會(huì)顯示他們的數(shù)量，減少輸出的列表信息，使得輸出結(jié)果不會(huì)太多。

事務(wù)ID是當(dāng)前事務(wù)的標(biāo)識(shí)，事務(wù)的id每次都會(huì)增加。Purge done for trx's n:o  是指凈化(purge)線程已經(jīng)完成的事務(wù)數(shù)。Innodb僅清除那些被當(dāng)前事務(wù)認(rèn)為不再需要的舊版本數(shù)據(jù)。那些未提交的舊事務(wù)可能會(huì)阻塞凈化線程并且消 耗資源。通過(guò)查看2次清除事務(wù)數(shù)之差，就可以知道是否發(fā)生了這種情況。少數(shù)情況下，凈化線程可能難以跟上更新的速度，2次查看值之差可能會(huì)越來(lái)越大；那 么，innodb_max_purge_lag  就派得上用場(chǎng)了。 "undo n:o"  顯示了凈化線程當(dāng)前正在處理的回滾日志號(hào)，如果當(dāng)前不處于活躍狀態(tài)，則它的值是 0。

History list length 6  是指在回滾空間中的未清除事務(wù)數(shù)。隨著事務(wù)的提交，它的值會(huì)增加；隨著清除線程的運(yùn)行，它的值會(huì)減小。

Total number of lock structs in row lock hash table  是指事務(wù)分配過(guò)的行鎖結(jié)構(gòu)總數(shù)。它和曾經(jīng)被鎖住過(guò)的行總數(shù)不一定相等，通常是一個(gè)鎖結(jié)構(gòu)對(duì)應(yīng)多行記錄。

MySQL中，每個(gè)連接如果沒(méi)有活動(dòng)的事務(wù)，則它的狀態(tài)是 not started ，如果有活動(dòng)的事務(wù)，則是 ACTIVE 。 注意，盡管事務(wù)是活動(dòng)的，但是其連接的狀態(tài)卻可能是 "睡眠(sleep)" - 如果是在一個(gè)有多條語(yǔ)句的事務(wù)里的話。Innodb  會(huì)同時(shí)顯示系統(tǒng)的線程號(hào)以及進(jìn)程號(hào)，這有助于利用gdb來(lái)調(diào)試或者其他類(lèi)似用途。另外，事務(wù)的狀態(tài)也會(huì)根據(jù)當(dāng)前實(shí)際狀態(tài)來(lái)顯示，例如 "讀取記錄 (fetching rows)" ，em>"更新(updating)"等等。"Thread declared inside InnoDB 400"  的意思是 Innodb 內(nèi)核正在運(yùn)行該線程，并且還需要400個(gè)票。Innodb 會(huì)根據(jù) innodb_thread_concurrency   的值來(lái)限制同時(shí)并發(fā)的線程數(shù)不超過(guò)它。如果線程當(dāng)前不在 Innodb 的內(nèi)核中運(yùn)行，則它的狀態(tài)可能是 "waiting in  InnoDB queue" 或 "sleeping before joining InnoDB queue" 。后面這 個(gè)狀態(tài)有點(diǎn)意思 - Innodb  為了避免有太多的線程同時(shí)搶著要進(jìn)入運(yùn)行隊(duì)列，那么就會(huì)嘗試讓這些線程進(jìn)入等待狀態(tài)(如果沒(méi)有足夠的空閑插槽(slot)的話)。這就可能會(huì)導(dǎo)致  Innodb 內(nèi)核中當(dāng)前活躍的線程數(shù)可能比 innodb_thread_concurrency  的值還小。某種負(fù)載環(huán)境下，這可能有助于減小線程進(jìn)入隊(duì)列的時(shí)間?？梢酝ㄟ^(guò)調(diào)整 innodb_thread_sleep_delay  來(lái)實(shí)現(xiàn)，它的單位是微妙。

mysql tables in use 1, locked 0  是指事務(wù)中已經(jīng)用過(guò)的數(shù)據(jù)表個(gè)數(shù)(已經(jīng)訪問(wèn)過(guò)了的)，以及被鎖的個(gè)數(shù)。Innodb 一般情況不會(huì)鎖表，因此鎖表數(shù)一般是0，除非是 ALTER TABLE  或者其他類(lèi)似 LOCK TABLES  的語(yǔ)句。

除了Innodb相關(guān)的特定信息外，一些基本信息可以通過(guò) 來(lái)查看，例如正在執(zhí)行什么語(yǔ)句，查詢(xún)ID號(hào)，查詢(xún)狀態(tài)等。

下面這部分顯示的是跟IO相關(guān)的具體信息：

1.--------
2.FILE I/O
3.--------
4.I/O thread 0 state: waiting for i/o request (insert buffer thread)
5.I/O thread 1 state: waiting for i/o request (log thread)
6.I/O thread 2 state: waiting for i/o request (read thread)
7.I/O thread 3 state: waiting for i/o request (write thread)
8.Pending normal aio reads: 0, aio writes: 0,
9. ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
10.Pending flushes (fsync) log: 0; buffer pool: 0
11.17909940 OS file reads, 22088963 OS file writes, 1743764 OS fsyncs
12.0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80 fsyncs/s

本部分顯示了IO助手線程狀態(tài) -  插入緩沖線程，日志線程，讀、寫(xiě)線程。它們分別對(duì)應(yīng)插入緩沖合并，異步日志刷新，預(yù)讀以及刷新臟數(shù)據(jù)。源自查詢(xún)的正常讀取是由正在運(yùn)行的查詢(xún)執(zhí)行的。在 Unix/Linux平臺(tái)下，總能看見(jiàn)4個(gè)線程，在Windows上可以通過(guò) innodb_file_io_threads  來(lái)調(diào)整。每個(gè)線程準(zhǔn)備好之后都能看到其狀態(tài)：waiting for i/o request  或者正在執(zhí)行特定的操作。

每個(gè)線程都會(huì)顯示正在進(jìn)行的操作數(shù)量 - 同時(shí)正要執(zhí)行或者正在執(zhí)行的操作數(shù)量。另外，正在執(zhí)行的 fsync  操作數(shù)量也會(huì)顯示出來(lái)。有寫(xiě)數(shù)據(jù)時(shí)，Innodb需要確保數(shù)據(jù)最終被寫(xiě)到磁盤(pán)上，只是把它們放在系統(tǒng)緩存里是不夠的。通常是調(diào)用 fsync()  來(lái)完成的。如果它的值一直很高，那意味這Innodb可能是處于IO負(fù)載較高狀態(tài)。注意，由線程執(zhí)行請(qǐng)求引發(fā)的IO請(qǐng)求是不計(jì)算在內(nèi)的，因此盡管系統(tǒng)的 IO負(fù)載較高，但是它們的值卻可能為 0。

接下來(lái)顯示的是IO操作的平均統(tǒng)計(jì)值，它們對(duì)于圖形顯示或者監(jiān)控很有用。
"16384 avg bytes/read"  是讀請(qǐng)求的平均值。隨機(jī)IO的話，每個(gè)頁(yè)的大小是16K，全表掃描或索引掃描時(shí)的預(yù)讀會(huì)導(dǎo)致這個(gè)值明顯的增加。因此，它體現(xiàn)了預(yù)讀的效率。

1.-------------------------------------
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.-------------------------------------
4.Ibuf for space 0: size 1, free list len 887, seg size 889, is not empty
5.Ibuf for space 0: size 1, free list len 887, seg size 889,
6.2431891 inserts, 2672643 merged recs, 1059730 merges
7.Hash table size 8850487, used cells 2381348, node heap has 4091 buffer(s)
8.2208.17 hash searches/s, 175.05 non-hash searches/s

本部分顯示了插入緩沖以及自適應(yīng)哈希索引的狀態(tài)。第一行顯示了插入緩沖的狀態(tài) -  段的大小以及空閑列表，以及緩沖中有多少記錄。接下來(lái)顯示了緩沖中已經(jīng)完成了多少次插入，有多少記錄已經(jīng)合并，有多少次合并已經(jīng)完成。合并次數(shù)除以插入次 數(shù)得到的比率可以反映出插入緩沖的效率如何。

Innodb采用哈希索引建立內(nèi)存頁(yè)索引形成自適應(yīng)哈希索引而不是采 B-tree  索引，得以加速行記錄到內(nèi)存頁(yè)的檢索。這里顯示了哈希表的大小，以及自適應(yīng)哈希索引使用了多少單元和緩沖。可以通過(guò)計(jì)算利用哈希索引檢索的次數(shù)以及沒(méi)利用 它檢索的次數(shù)來(lái)了解哈希索引的效率。

當(dāng)前對(duì)自適應(yīng)哈希索引基本沒(méi)有什么辦法可以調(diào)整它，主要還是用于查看。

1.---
2.LOG
3.---
4.Log sequence number 84 3000620880
5.Log flushed up to   84 3000611265
6.Last checkpoint at  84 2939889199
7.0 pending log writes, 0 pending chkp writes
8.14073669 log i/o's done, 10.90 log i/o's/second

接下來(lái)顯示的是Innodb的日志子系統(tǒng)相關(guān)信息?？梢钥吹疆?dāng)前的日志序列號(hào) -  相當(dāng)于Innodb自從表空間開(kāi)始創(chuàng)建直到現(xiàn)在已經(jīng)寫(xiě)入日志文件的總字節(jié)數(shù)。還可以看到日志已經(jīng)刷新到哪個(gè)點(diǎn)，同樣也可以根據(jù)最后檢查點(diǎn)計(jì)算出還有多少日 志沒(méi)有刷新到文件中去。Innodb采用模糊檢查點(diǎn)，因此這行顯示的是已經(jīng)從緩沖池中刷新到文件的日志序列號(hào)。由于更高的日志序列號(hào)可能不會(huì)被立刻刷新到 日志文件中去，因此日志序列號(hào)不能被覆蓋掉。通過(guò)監(jiān)控刷新到哪個(gè)日志的日志序列，可以判定 innodb_log_buffer_size  的設(shè)置是否合理，如果看到超過(guò) 30% 的日志還沒(méi)有刷新到日志文件中，則需要考慮增加它的值了。

另外，還能看到日志寫(xiě)入以及檢查點(diǎn)的數(shù)目。根據(jù)日志 I/O  操作的數(shù)目可以區(qū)分開(kāi)表空間相關(guān)的IO請(qǐng)求和日志IO請(qǐng)求數(shù)量，進(jìn)而可以確定到底需要幾個(gè)日志文件。注意，innodb_flush_log_at_trx_commit   的值可以影響到日志寫(xiě)操作的代價(jià)高或低。如果  innodb_flush_logs_at_trx_commit=2，則日志是寫(xiě)到系統(tǒng)緩存，然后再順序?qū)懙饺罩疚募校虼讼鄬?duì)會(huì)快很多。

1.----------------------
2.BUFFER POOL AND MEMORY
3.----------------------
4.Total memory allocated 4648979546; in additional pool allocated 16773888
5.Buffer pool size   262144
6.Free buffers       0
7.Database pages     258053
8.Modified db pages  37491
9.Pending reads 0
10.Pending writes: LRU 0, flush list 0, single page 0
11.Pages read 57973114, created 251137, written 10761167
12.9.79 reads/s, 0.31 creates/s, 6.00 writes/s
13.Buffer pool hit rate 999 / 1000

這部分顯示了緩沖池和內(nèi)存的利用率相關(guān)信息?？梢钥吹絀nnodb分配的所有內(nèi)存(有些時(shí)候可能比你設(shè)置的還要多點(diǎn))，以及額外的內(nèi)存池分配情況 (可以檢查它的大小是否正好)，緩沖池總共有多少個(gè)內(nèi)存頁(yè)，有多少空閑內(nèi)存頁(yè)，數(shù)據(jù)庫(kù)分配了多少個(gè)內(nèi)存頁(yè)以及有多少個(gè)臟內(nèi)存頁(yè)。從這些信息中，就可以判斷 內(nèi)存緩沖池是否設(shè)定合理，如果總是有大量空閑內(nèi)存頁(yè)，則不需要設(shè)置那么多內(nèi)存，可以適當(dāng)減小一點(diǎn)。如果空閑內(nèi)存頁(yè)為  0，這種情況下數(shù)據(jù)庫(kù)內(nèi)存頁(yè)就不一定會(huì)和緩沖池的總數(shù)一致，因?yàn)榫彌_池還需要保存鎖信息，自適應(yīng)哈希索引以及其他系統(tǒng)結(jié)構(gòu)等信息。

等待中的讀寫(xiě)是指內(nèi)存緩沖池級(jí)別的請(qǐng)求。Innodb可能會(huì)把多個(gè)文件級(jí)別的請(qǐng)求合并到一個(gè)上，因此各不相同。我們還可以看到Innodb提交的各 種不同類(lèi)型的IO，LRU內(nèi)存頁(yè)中需要刷新的頁(yè) - 臟內(nèi)存頁(yè)，它們不會(huì)被長(zhǎng)時(shí)間存??；刷新列表 -
檢查點(diǎn)進(jìn)程處理完之后需要刷新的舊內(nèi)存頁(yè)；獨(dú)立內(nèi)存頁(yè) - 獨(dú)立的寫(xiě)內(nèi)存頁(yè)。

我們還可以看到內(nèi)存頁(yè)總共讀寫(xiě)了多少次。已經(jīng)創(chuàng)建的內(nèi)存頁(yè)是當(dāng)前一個(gè)內(nèi)存頁(yè)中的內(nèi)容沒(méi)有讀取到內(nèi)存緩沖池中時(shí)，專(zhuān)門(mén)為新數(shù)據(jù)創(chuàng)建的空內(nèi)存頁(yè)。

最后我們可以看到緩沖池的命中率，它預(yù)示著緩沖池的效率。1000/1000 相當(dāng)于 100%  的命中率。不過(guò)這樣也很難說(shuō)明緩沖池的命中率就足夠高了，這要需要根據(jù)不同的負(fù)載環(huán)境而定。通常情況下，950/1000  就夠了，有些時(shí)候在IO負(fù)載較高的環(huán)境下，命中率可能為 995/1000。

1.--------------
2.ROW OPERATIONS
3.--------------
4.0 queries inside InnoDB, 0 queries in queue
5.1 read views open inside InnoDB
6.Main thread process no. 10099, id 88021936, state: waiting for server activity
7.Number of rows inserted 143, updated 3000041, deleted 0, read 24865563
8.0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

最后一部分，顯示了數(shù)據(jù)行操作以及一些系統(tǒng)信息相關(guān)情況。

一開(kāi)始顯示了Innodb線程隊(duì)列狀態(tài) - 有多少線程處于等待或活躍的。Innodb內(nèi)部打開(kāi)了多少讀視圖 -
這是在事務(wù)開(kāi)始后，但是當(dāng)前還沒(méi)有活躍語(yǔ)句的情況，Innodb主線程的狀態(tài)控制了系統(tǒng)操作調(diào)度的數(shù)量 -  刷新臟內(nèi)存頁(yè)、檢查點(diǎn)、凈化線程、刷新日志、合并插入緩沖等。 "state"  的值則表示了主線程當(dāng)前的狀態(tài)。

接下來(lái)可以看到自從系統(tǒng)啟動(dòng)以來(lái)，所有的數(shù)據(jù)行操作數(shù)量及其平均值。它們可以很方便地用于監(jiān)控以及畫(huà)出系統(tǒng)狀態(tài)圖，數(shù)據(jù)行操作次數(shù)可以很好的衡量 Innodb的負(fù)載。不是所有的數(shù)據(jù)行操作帶來(lái)的負(fù)載都是一樣的，存取10字節(jié)的行比10Mb的行相比會(huì)小了很多，不過(guò)相對(duì)于查詢(xún)的總次數(shù)來(lái)說(shuō)這個(gè)信息可 是有用的多了，差別也很大。

還有一點(diǎn)需要注意的是，SHOW INNODB STATUS 不是一成不變的，有些時(shí)間點(diǎn)上可能會(huì)不相符。SHOW INNODB  STATUS結(jié)果中，不同時(shí)間可能會(huì)顯示不同結(jié)果，因此有些時(shí)候可能會(huì)看到?jīng)_突的信息。這是由于設(shè)計(jì)時(shí)需要由全局鎖提供一致性信息，導(dǎo)致了大量的開(kāi)銷(xiāo)。

“MySQL中的SHOW ENGINE INNODB STATUS舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！