show engine innodb status分析

當前活躍的事務:

------------

TRANSACTIONS

------------

Trx id counter080157601

Purge done for trx's n:o <0 80154573 undo n:o <0 0

History list length 6

Total number of lock structs in row lock hash table 0

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672

MySQL thread id 8080, query id 728900 localhost root

show innodb status

---TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442

mysql tables in use 1, locked 0

MySQL thread id 8079, query id 728899 localhost root Sending data

select sql_calc_found_rows * from b limit 5

Trx read view will not see trx with id>= 0 80157601, sees <0 80157597

---TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166

mysql tables in use 1, locked 0

MySQL thread id 8078, query id 728898 localhost root Sending data

select sql_calc_found_rows * from b limit 5

Trx read view will not see trx with id>= 0 80157600, sees <0 80157596

---TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114

mysql tables in use 1, locked 0

MySQL thread id 8077, query id 728897 localhost root Sending data

select sql_calc_found_rows * from b limit 5

Trx read view will not see trx with id>= 0 80157599, sees <0 80157595

---TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400

mysql tables in use 1, locked 0

MySQL thread id 8076, query id 728896 localhost root Sending data

select sql_calc_found_rows * from b limit 5

Trx read view will not see trx with id>= 0 80157598, sees <0 80157594

若是鏈接數量很大，InnoDB只能打印出其中的一部分，以維持整個列表的長度。

Transaction id是當前事務的標識符。Purge done for trx's n:o是回收程序啓動事務的數 量。若是回收程序沒有運行事務，InnoDB只能回收舊版本。舊的未提交事務可能會阻塞回收進程而吃掉資源。經過查看當前事務數和 最近一次回收事務數的差值就能夠發現這個問題。在某些狀況下，回收程序效率很低而要維持更新率，在這種狀況下差值也會增長，這時innodb_max_purge_lag會有所幫助。"undo n:o"顯示回收程序正在處理的undo日誌記錄數，若是當前沒有回收程序運行，則該值爲0。

History list length是在回滾段中爲回收的事務數。當更新事務提交時該值增長，當回收線程運行時該值減小。

Total number of lock structs in row lock hash table是全部事務分配的行鎖結構數。該值並不等於鎖住的行數－由於一個鎖結構中包含不少行。

MySQL的鏈接要麼是not started狀態（該鏈接沒有活動的事務），要麼是ACTIVE狀態（有活動事務）。注意，儘管鏈接是"SLEEP"狀態，但事務也能夠是活躍的－若是事務中有多個語句。事務狀態就是事務正在作什麼，如"fetching rows","updating"。"Thread declared inside InnoDB 400"意思是線程正在InnoDB內核中運行，當前還能夠有400個線程能夠進來。InnoDB限制內核中的併發線程數使用變量innodb_thread_concurrency 。若是線程沒在InnoDB內核中運行，狀態應該是"waiting in InnoDB queue" 或"sleeping before joining InnoDB queue"。爲避免太多線程競爭進入InnoDB隊列，InnoDB有時會讓線程先sleep，而不是wait。這樣就會使InnoDB內核中的活躍線程少於innodb_thread_concurrency。這會減小線程等待進入隊列的時間，能夠調整innodb_thread_sleep_delay的值，該值爲微秒。

mysql tables in use 1, locked 0是由線程正使用的表數，和線程鎖住的表數。InnoDB通常不會鎖表，所以該值通常爲0，除非ALTER TABLE或LOCK TABLES類似的操做。

文件I/O:

--------

FILE I/O

--------

I/O thread0state: waiting for i/o request(insert buffer thread)

I/O thread1state: waiting for i/o request(log thread)

I/O thread2state: waiting for i/o request(read thread)

I/O thread3state: waiting for i/o request(write thread)

Pending normal aio reads:0, aio writes:0,

ibuf aio reads:0, log i/o's: 0, sync i/o's:0

Pending flushes(fsync)log:0; buffer pool:0

17909940OS file reads,22088963OS file writes,1743764OS fsyncs

0.20reads/s,16384avg bytes/read,5.00writes/s,0.80fsyncs/s

IO的四個進程（括號中的名字）。插入緩存合併，異步日誌刷新，read－ahead和髒緩存刷新。若是線程準備好了則爲waiting for i/o request狀態，不然它就正在執行某種操做。

Number of pending operation is shown for each of helper threads - these are amount of operations queued for execution or being executed at the same time. Also number of pending fsync operations is displayed. For writes Innodb has to ensure data makes it to the disk - just passing it to OS cache is not enough. This is typically done by calling fsync() for modified files. Constant high values for any of these variables is indication of IO bound workload. Note however - IO requests submited by threads executing requests are not accounted here so you may have these at zeroes while workload being IO bound still.

Next, number of file IO operations is shown as well as computed averages. This is parameters which is great for graphing and monitoring.

"16384 avg bytes/read"shows average size of read requests. For random IO these should be 16K - page size, for full table scan or index scan read-ahead may be performed which can increase average read size significantly. So you can think about this value as read-ahead efficiency.

-------------------------------------

INSERT BUFFER AND ADAPTIVE HASH INDEX

-------------------------------------

Ibuf for space0: size1, free list len887, seg size889, is not empty

Ibuf for space0: size1, free list len887, seg size889,

2431891inserts,2672643merged recs,1059730merges

Hash table size8850487, used cells2381348, node heap has4091buffer(s)

2208.17hash searches/s,175.05non-hash searches/s

This section shows insert buffer and adaptive hash status. First line shows status of insert buffer - segment size and free list as well as if

there are any records is insert buffer. Next it shows how many inserts were done in insert buffer, how many recs were merged and how many merges did it took. Ratio of number of merges to number of inserts is pretty much insert buffer efficiency.

Adaptive hash index is hash index Innodb builds for some pages to speed up row lookup replacing btree search with hash search. This section shows hash table size, number of used cells and number of buffers used by adaptive hash index. You can also see number of hash index lookups and number of non-hash index lookups which is indication of hash index efficiency.

There is currently not much you can do to adjust adaptive hash index or insert buffer behavīor so it is pretty much for informational purposes only.

---

LOG

---

Log sequence number843000620880

Log flushed up to843000611265

Last checkpoint at842939889199

0pending log writes,0pending chkp writes

14073669log i/o's done, 10.90 log i/o's/second

Log section provides information about log subsystem of Innodb. You can see current log sequence number - which is amount of bytes Innodb has written in log files since system tablespace creation. You can also see up to which point logs have been flushed - so how much data is unflushed in log buffer as well as when last checkpoint was performed. Innodb uses fuzzy checkpointing so this line hold log sequence, all changes up to which has been flushed from buffer pool. Changes having higher log sequences may still only be recored in logs and not flushed from buffer pool so such log sequences can't be overwritten in log files. By monitoring log sequence number and value up to which logs have been flushed you can check if yourinnodb_log_buffer_sizeis optimal - if you see more than 30% of log buffer size being unflushed you may want to increase it.

You also can see number of pending normal log writes and number of checkpoint log writes. Number of log/io operations allows to separate tablespace related IO from log related IO so you can see how much IO your log file requires. Note depending on yourinnodb_flush_log_at_trx_commitvalue your log writes may be more or less expensive. If innodb_flush_logs_at_trx_commit=2 log writes are done to OS cache, and being sequential writes these logs writes are pretty fast.

----------------------

BUFFER POOL AND MEMORY

----------------------

Total memory allocated4648979546; in additional pool allocated16773888

Buffer pool size262144

Free buffers0

Database pages258053

Modified db pages37491

Pending reads0

Pending writes: LRU0, flush list0, single page0

Pages read57973114, created251137, written10761167

9.79reads/s,0.31creates/s,6.00writes/s

Buffer pool hit rate999/1000

該部分描述了內存的使用狀況。包括的信息有：InnoDB分配的總內存，額外分配的內存，緩存池中的頁數，空閒頁數，數據庫頁和髒頁數。從這些值中 能夠看出是否InnoDB緩存分配得恰當－若是總有不少空閒頁，代表數據庫要比內存小，能夠把innoDB緩存調小些。若是空閒頁爲0，那麼數據庫頁不會 和緩存容量相同，由於還要存鎖、索引和其餘得系統結構。

Pending reads and writes are pending requests on buffer pool level. Innodb may merge multiple requests to one on file level so these are different. We can also see different types of IO submited by Innodb - pages to be flushed via LRU pages - dirty pages which were not accessed long time, flush list - old pages which need to be flushed by checkpointing process and single page - independent page writes.

We can also see number of pages being read and written. Created pages is empty pages created in buffer pool for new data - when previous page content was not read to the buffer pool.

Finally you can see buffer pool hit ratio which measures buffer pool efficiency. 1000/1000 corresponds to 100% hit rate. It is hard to tell what buffer pool hit rate is good enough - it is very workload dependent. Sometimes 950/1000 will be enough, sometimes you can see IO bound workload with hit rate of 995/1000.

--------------

ROW OPERATIONS

--------------

0queries inside InnoDB,0queries in queue

1read views open inside InnoDB

Main thread process no.10099, id88021936, state: waiting for server activity

Number of rows inserted143, updated3000041, deleted0, read24865563

0.00inserts/s,0.00updates/s,0.00deletes/s,0.00reads/s

Finally last section - row operations which shows activity on the row basics and some system information.

It shows innodb thread queue status - how many threads are waiting and being active. How many read views are open inside Innodb - this is when transaction was started but no statement is currently active, state of Innodb main thread which controls scheduling of number of system operations - flushing dirty pages, checkpointing, purging, flusing logs, doing insert buffer merge. Values for"state"field are rather self explanatory.

You can also see number of rows operation since system startup as well as average values. This is also very good values to monitor and graph - row operations is very good measure of Innodb load. Not all row operations are created equal of course and accessing of 10 byte rows is much cheaper than accessing 10MB blog, but it is still much more helpful than number of queries, which is even more different.

One more thing to note - SHOW INNODB STATUS is not consistent - it does not correspond to some particular point in time. Different lines in SHOW INNODB STATUS populated in different point in times, so sometimes you may see a bit conflicting information. This is by design as requiring global lock to provide consitent information would cause significant overhead.