show engine innodb status\G 输出内容解释。

1. show engine innodb status
http://blog.csdn.net/longxibendi

2. 宏观认识
4个问题：
1.mysql io
1.mysql并发低，是因为io
io的问题么？
2. 为什么相同硬件，oracle mysql qps
oracle mysql的 qps高？
oracle比mysql
3. 如果一次物理io,
io, 500nm
io,耗时500nm
500nm，那会怎样？
4. buffer_pool 36G, mysqld
36G,没有连接进来，mysqld
mysqld占用内存要
多一些 ？

3. 宏观认识
1. INNODB MONITOR OUTPUT
2. SEMAPHORES
3. LASTEST DETECTED DEADLOCK

4. 宏观认识
1.TRANSACTIONS

5. 宏观认识
1.FIFE I/O
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.LOG

6. 宏观认识
1.BUFFER POOL AND MEMORY
2.ROW OPERATIONS
6

7. INNODB MONITOR OUTPUT
1. 显示当前时间点。
2.计算最近的43秒内的部分参数的平均值。(不受用户控制，一般不会超过60秒)
1. innodb_status_file=1，会每隔15s，将show engine innodb status输出结果，存放到
var/innodb_status.pid 文件中，pid是进程ID.
7

8. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Innodb 的并发控制：
1.Innodb mutex : 特点，不可重入；短期持有；
作用，保护系统中的全局资源，临界区；
例如，buffer pool mutex; 对整个buffer_pool 加mutex.比如页面分裂、btree调整。
buffer header mutex; 对页面的操作，需要持有该mutex。 Adaptive Hash Index mutex。
log sys mutex; 写事物日志，串行写入，非并行。group commit?
.
8

9. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Innodb 的并发控制：
2.Innodb latch : 特点，读写锁 (RW_LOCK)；
作用，保护系统中的共享buffer；
例如，page latch.对一个page 进行read/write。
9

10. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Innodb 的并发控制：
3.Innodb pin : 特点，一个标识，一个在mutex保护下的count值，不是一个锁；
作用，如果count !=0,内存中的page不能被替换出；
例如，page pin count。
10

11. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Innodb 的并发控制：
4.mysql 其他lock : 特点，锁住mysql/innodb资源；
作用，锁表，锁数据；
例如，select * from game.user where id <= 10024 for update ;(锁数据)
flush tables with read lock;( 所有表 只读)
lock table game.user write ;( 表置写锁)
1. innodb_status_file=1，会每隔15s，将show engine innodb status输出结果，存放到
var/innodb_status.pid 文件中，pid是进程ID.
11

12. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
1.各种mutex & rw_lock.
2.Kernel mutex. 5.6拆了。
12

13. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
各种故事:
1.
(空表加字段，会获取table cache锁，一个全局锁，整个instance都会被锁住，当多个ddl提交的时
候，且bufferpool超大的时候，每个ddl都会触发一个bufferpool扫描，那就类似于一个超长锁了。
整个应用处于僵死状态。)
(MySQL加字段，一直采用的是Create Tmp Table + Rename + Drop Old Table的方式，而在Drop Old
Table阶段，InnoDB会两次遍历Buffer Pool，此时加Buffer Pool Mutex遍历，会引起一定时间的
Hang。)
2.mysql 5.0.51b ,80天的binlog.(一天5G)。调整expire_logs_days=7; 执行flush logs;阻塞写。
2.
3.drop table ,阻塞 其他表写。
3.
4.自适应hash索引；ibbackup 备份程序；子查询 锁。
13

14. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Innodb 的并发控制 参数：
Innodb_thread_concurrency (默认是8， 0～1000)
(innodb内核并发线程参数)
Innodb_sync_spin_loops (默认是20，0～4,294,967,295)
(在thread被挂起之前，等待innodb mutex被释放的 等待次数)
1.大量的thread等待信号量原因是： 磁盘io读写问题，innodb 内部的 上下文切换导致。
14

15. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
Kernel mutex & 争用：
spin-wait, 一个线程获取mutex，且 没有得到。就是一次check 。
spin-wait cycle，一个线程，在不断获取mutex,不断的check,就是一个spin-wait cycle。
OS wait， 线程放弃 spin-wait,进入sleep，至少消耗一个OS wait。
Innodb_sync_spin_loops (默认是20，0～4,294,967,295)。
innodb_spin_wait_delay(默认是6， 0 ~4,294,967,295)
举例：
check,check,check,check; sleep ;sleep;sleep ,;check,check,check,check;
Innodb_sync_spin_loops,线程在一个spin-wait cycle中，check的次数。本例为 4。
Innodb_spin_wait_delay,线程在相邻spin-wait cycle的时间。单位为us。本例为3。
1.会不会因为innodb_sync_spin_loops太少，导致占用更多cpu上下文切换，大小是多少比较合
适？
2.Linux，一个cpu周期(时间片)，耗时多长，一个spin-wait cycle耗时多长？
15

16. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
几个字段：
Mutex spin waits :一个线程获取mutex，但mutex不可用(没获取到)，线程在一个spin wait 执行check的次数。
Rounds:线程在spin-wait cycle中 ，执行check mutex的总数。
Rw-share 共享锁，RW-excl 排他锁(exclusive)。
OS waits:线程放弃spin waiting,进行sleep的总数。
signal count 22133482=OS waits 13850218+ OS waits 8365537+ OS waits 327946
1.大量的thread等待信号量原因是： 磁盘io读写问题，innodb 内部的 上下文切换导致。
16

17. SEMAPHORES
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
waiters flag 0
wait is ending
--Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
waiters flag 0
wait is ending
Mutex spin waits 5672442, rounds 3899888, OS waits 4719
RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163
几个字段：
Lock var 0, mutex状态标志，locked=1,free=0。
Waiters flag 0, 当前waiter的编号。
Wait is ending，waiter状态。
表示，当前的mutex是free状态，等待该mutex的线程的等待状态 为0，都在等待该mutex.但该mutex已经是
free,只不过调度器还没有让线程处于运行状态。线程等待调度器运行。
1.大量的thread等待信号量原因是： 磁盘io读写问题，innodb 内部的 上下文切换导致。
17

18. SEMAPHORES
Kernel_mutex 的例子：
----------
--Thread 140370743510784 has waited at trx0trx.c line 1184 for 0.0000 seconds the semaphore:
Mutex at 0x2b0ccc8 '&kernel_mutex', lock var 1
waiters flag 0
--Thread 140370752542464 has waited at trx0trx.c line 1772 for 0.0000 seconds the semaphore:
Mutex at 0x2b0ccc8 '&kernel_mutex', lock var 1
waiters flag 0
--Thread 140088222295808 has waited at trx0trx.c line 1184 for 0.0000 seconds the semaphore:
Mutex at 0x2b0ccc8 '&kernel_mutex', lock var 1
waiters flag 0
几个字段：
Lock var 0, mutex状态标志，locked=1,free=0。
Waiters flag 0, 当前waiter的编号。
Wait is ending，waiter状态。
表示，当前的kernel_mutex是lock状态，等待该mutex的线程的等待状态 为0，都在等待该mutex.
1.大量的thread等待信号量原因是： 磁盘io读写问题，innodb 内部的 上下文切换导致。
18

19. SEMAPHORES
1. Semaphores .进程间相互通信，避免多个进程共享资源时发生冲突。(起并发控制作用)
19

20. LATEST FOREIGN KEY ERROR
Foreign key error 原因：
1.update/delete/insert 的数据 ,依赖其他表中的行数据。
2. 删除/修改 一列时，这个列会关联到其他表。
3.Rename /drop table。
1.Error 150 , Error 1451, Error 1452 ,foreign key constraint failed
2.Error 1025 ,rename/drop table
3.准入不允许 foreign key 。
20

21. LATEST FOREIGN KEY ERROR
Foreign key error 原因：
1.update/delete/insert 的数据 ,依赖其他表中的行数据。
2. 删除/修改 一列时，这个列会关联到其他表。
3.Rename /drop table。
1.Error 150 ,Error 1451,Error 1452 ,foreign key constraint failed
2.Error 1025 ,rename/drop table
3.准入不允许 foreign key 。
21

22. LATEST DETECTED DEADLOCK
几个ID：
1. process no 13744 , mysqld 进程的PID 。(pstree mysql –p |grep mysqld)
2. OS thread id 1179187552 , 操作系统 线程 id。(一个mysql 连接,对应一个)
3.MySQL thread id 96237550 , connect id 。(show processlist; 第一个字段)
4.query id 2547648761 , 本次query id。(同一个链接，发一些 sql，每次 sql对应一个)
22

23. LATEST DETECTED DEADLOCK
1.ERROR 1213(40001)
23

24. LATEST DETECTED DEADLOCK
1.回滚开销小的事物。
2.如何减少、消除死锁。
3.死锁的影响 。为什么主库 cpu使用率高？
4.在不改mysql代码的情况下，如何提高并发量？
24

25. TRANSACTIONS
------------
TRANSACTIONS
------------
Trx id counter 0 3638031820
Purge done for trx's n:o < 0 3637930396 undo n:o < 0 0
History list length 19988
Total number of lock structs in row lock hash table 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 20150, OS thread id 1162877280
MySQL thread id 119512286, query id 46504256930 localhost root
show engine innodb status
---TRANSACTION 0 3638031818, not started, process no 20150, OS thread id 1196996960
MySQL thread id 119512319, query id 46504256929 10.36.125.38 vs_ipad
几个字段：
Trx id counter 0 3638031820 。 当前事务ID可用最大值 。下一个事物从这个ID 开始。一直增加。
Purge done for trx‘s n:o < 0 3637930396 undo n:o < 0 0。事物ID小于此值的，已完成flush dirty data及清理undo。
History list length 19988。在undo空间，没有purge的事物数。
Total number of lock structs in row lock hash table 0。所有事物持有行锁的结构体个数。每个行锁结构体有多行
数据。
25

26. TRANSACTIONS
---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
几个字段：
ACTIVE/not started 。 每个TRANSACTION都会是这2个状态中的一种。TRANSACTION能够是ACTIVE,即使这个连接
是SLEEP状态(这个事物，会执行多个sql)。
Sending data,fetching rows。发送data,获取数据。
Insite InnoDB 442。线程正在innodb 内核 ,还有 442个tickets使用。
Use 1,locked 0。有1个表，在被访问，0个lock.
Innodb 线程三种状态：
Running Inside Innodb，sleeping before joining InnoDB queue 和waiting in InnoDB queue.
1. innodb_thread_sleep_delay ,在进入innodb queue，需要等待的时间。默认10,000us.
2. innodb_thread_concurrency
innodb_thread_concurrency。
26

27. TRANSACTIONS
if (thread->n_tickets_to_enter_innodb > 0)
{
thread->n_tickets_to_enter_innodb--; 只要tickets不为0，都可以自由进出innodb内核。
ENTER;
}
retry:
if (entered_thread < innodb_thread_concurrency)
{
entered_threads++;
thread->n_tickets_to_enter_innodb = innodb_concurrency_tickets;
ENTER;
}
if (innodb_thread_sleep_delay > 0)
{
innodb_thread_sleep_delay
thread_sleep(innodb_thread_sleep_delay
innodb_thread_sleep_delay);
}
goto retry; // (only once)
(only
WAIT_IN_FIFO_QUEUE;
thread->n_tickets_to_enter_innodb = innodb_concurrency_tickets;
ENTER;
1. innodb_thread_sleep_delay check
innodb_thread_sleep_delay。线程先check delay
check是否可以进入内核，如果不可以，delay
delay这么长时
间，再check
check
check一次，如果还不能进入，则线程进入一个FIFO FIFO
FIFO队列中。
2. innodb_concurrency_tickets 默认为500.
500.
27

28. FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 256, 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
112084404 OS file reads, 29836003 OS file writes, 2038246 OS fsyncs
286.27 reads/s, 82658 avg bytes/read, 2.96 writes/s, 0.71 fsyncs/s
几个字段：
4个IO线程，其功能见之前分享。
Pending normal aio reads， aio writes: 。 异步读、写 PAGE 的个数。
Ibuf aio reads: insert buffer 。 异步读次数，log i/o’s 日志i/o，sync i/o 。
Pending flushes (fsync) log: 0; buffer pool: 0 。 同步写log次数；写bp次数。
112084404 OS file reads, 29836003 OS file writes, 2038246 OS fsyncs 。 OS 级别、读、写总次数。OS级别fsync次数。
286.27 reads/s, 82658 avg bytes/read, 2.96 writes/s, 0.71 fsyncs/s 。过去这段时间的均值。
1. 同步写，异步写。sync/fsync sync只是将所有修改过的块的缓存排入写队列，然后就返回，
sync/fsync
sync/fsync。
它并不等待实际I / O操作结束。数fsync只引用单个文件，它等待I / O结束，然后返回。
2. 哪些异步写，哪些同步写？
3.这里区分 随机、顺序 io 了么？
28

29. INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 12, seg size 14,
483766 inserts, 483766 merged recs, 449532 merges
Hash table size 50999537, node heap has 7589 buffer(s)
16377.23 hash searches/s, 1572.67 non-hash searches/s
几个字段：
Ibuf: size 1, free list len 12, seg size 14。Insert buffer，已使用1,空闲length 12, 一共14.单位page.
483766 inserts, 483766 merged recs, 449532 merges。 一共insert数，merge条数，merge次数。
Hash table size 50999537, node heap has 7589 buffer(s)。
16377.23 hash searches/s, 1572.67 non-hash searches/s。通过/没通过 hash找到的page。
1. Adaptive hash，维护索引叶页面中所有记录的索引键值(或键值前缀)到索引叶页面位置的Hash
映射关系，能够根据索引键值(前缀)快速定位到叶页面满足条件记录的Offset，减少了B+树
Search Path的代价，将B+树从Root页面至Leaf页面的路径定位，优化为Hash Index的快速查询。
2. Adaptive，意味着不是所有的叶页面都会以Hash索引维护，叶页面进入Hash索引的条件是：同
种类型的操作(Scan/Insert…)，命中同一叶页面的次数，超过此页面记录数量的1/16，则可将当前
叶页面加入Hash索引，用以优化后续可能的相同Search Path？
3.整个Adaptive Hash Index使用一个mutex保护。有什么问题？
29

30. LOG
---
LOG
---
Log sequence number 84 3000620880 当前LSN (LSN单位本身是b)
Log flushed up to 84 3000611265 FLUSH LSN 。已刷到磁盘的LSN。
Last checkpoint at 84 2939889199 LAST CHK 。Data和log都刷到磁盘的LSN。
0 pending log writes, 0 pending chkp writes
14073669 log i/o's done, 10.90 log i/o's/second
1. Innodb的 checkpoint 分类。
2. 为什么有checkpoint，可以不掉不。起什么作用。
3. (3000620880 – 3000611265)/1024= 9Kb . 没刷到磁盘。 30% of log buffer size being unflushed you
may want to increase it
4. innodb_flush_logs_at_trx_commit。
30

31. BUFFER POOL AND MEMORY
---------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 42376766570; in additional pool allocated 21381888
Dictionary memory allocated 1394720
Buffer pool size 2359296
Free buffers 0
Database pages 2346920
Modified db pages 198995
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 497948034, created 5732505, written 267036271
8.88 reads/s, 0.02 creates/s, 4.75 writes/s
Buffer pool hit rate 998 / 1000
几个字段
Total memory allocated 42376766570; 。当前mysqld进程 使用物理内存，单位字节。
in additional pool allocated 21381888 。innodb_additional_mem_pool_size 大小，单位字节。
Buffer pool size 2359296 。BP ，单位是page。
Pages read 497948034, created 5732505, written 267036271。读、写、创建 总page。不断增加。
8.88 reads/s, 0.02 creates/s, 4.75 writes/s。过去43秒，平均读、写、创建page个数。
Buffer pool hit rate 998 / 1000。BP命中率。
1. Innodb的 checkpoint 分类。
2. 为什么有checkpoint，可以去掉不。起什么作用。
31

32. BUFFER POOL AND MEMORY
1. 每个page占用 800字节内存，作为buffer header。42376766570怎么得出的？
32

33. ROW OPERATIONS
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 10099, id 88021936, state: waiting for server activity
Number of rows inserted 143, updated 3000041, deleted 0, read 24865563
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
几个字段
0 queries inside InnoDB, 0 queries in queue。Innodb内核query，队列中的query。
1 read views open inside InnoDB。1个事物已经开始，但不是处于active状态。
Buffer pool size 262144 。BP ，单位是page。
Main thread process no. 10099, id 88021936, state: waiting for server activity。主线程在等server发请求。
Number of rows inserted 143, updated 3000041, deleted 0, read 24865563。mysql启动之后，i/u/d/r 行数。
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s。过去43秒，i/u/d/r 行数。
33

34. 总结
1.单行数据大，有什么问题？
2.参数、软件&硬件平衡，最大化利用硬件资源。
http://www.mysqlperformanceblog.com/2011/12/02/kernel_mutex-problem-or-double-throughput-with-single-
variable/
http://www.mysqlperformanceblog.com/2010/05/24/tuning-innodb-concurrency-tickets/
34

35. 谢谢
http://blog.csdn.net/longxibendi
35