showengineinnodbstatus详解
很多⼈让我来阐述⼀下 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.Per cond averages calculated from the last 44 conds
考研的路上⾸先要确认这是⾄少统计了 20-30 秒的样本数据。如果平均统计间隔是0或1秒，那么结果就没什么意义了。
说实在的我不喜欢InnoDB提供的平均值，因为很难取得合理的平均间隔统计值，如果你是写脚本来取得 SHOW INNODB STATUS 结果的话，那么最好取得全局的统计结果，然后取得平均值。当然了，直接查看输出的结果信息也是很有⽤的。
下⼀部分显⽰了信号(Semaphores)相关信息：
1.----------
2.SEMAPHORES
3.----------
4.OS WAIT ARRAY INFO: rervation count 13569, signal count 11421
5.--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 conds the maphore:
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 conds the maphore:
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个部分。⼀部分是当前的等待，这部分只是包含了在⾼并发环境下的全部记录，因此 InnoDB 会频繁回退到系统等待。如果等待是通过⾃旋锁来解决的话，那么这些信息就就不会显⽰了。
通过这部分信息，你就会知道系统负载的热点在哪了。不过这需要了解⼀下源码相关的知识 - 从上⾯的信息中就可以看出来是哪个源码⽂件中的哪⾏(不同的版本结果可能不同)，只是从这⾥却看不出来任何信息。尽管如此，还是可以从⽂件名中猜到⼀些东西 - ⽐如本例中，⽂件名 "buf0buf.ic" 预⽰着和⼀些缓冲池争夺有关系。如果想了解更多，就去看源码吧。
还有⼀些关于等待的更多细节。"lock var" 表⽰当前的 mutex 对象的值(被锁住 = 1 / 释放 = 0) 值，"waiters flag" 表⽰当前的等待个数。另外，本例中还可以看到等待状态信息 "wait is ending"，这表⽰ mutex 已经释放，但是系统调度线程还正在处理。
第⼆块是事件统计 - "rervation count" 和 "signal count" 显⽰了 innodb 使⽤内部同步阵列的活跃程度 - 时间⽚(slot)分配以及线程信号使⽤同步阵列的频繁程度。这些统计信息可以⽤于表⽰ innodb 回退到系统等待的频率。还有关于系统等待的直接相关信息，可以看到"OS Waits"的互斥信号灯(mutexes)，以及读写锁。这些信息中显⽰了互斥锁和共享锁。系统等待和 "保留(rervation)" 不完全⼀样，在回退到⽤sync_array 的复杂等待模式前，innodb 会尝试 "输出(yield)" 到系统，希望下⼀次调度时间对象⾥命名线程已经释放了。系统等待相对较慢，如果每秒发⽣了上万次系统等待，则可能会有问题。另⼀个观察⽅法是查看系统状态中的上下⽂(context)交换频率。
另⼀块重要的信息是 "spin waits" 和 "spin rounds" 的数量。相较于系统等待，⾃旋锁是低成本的等待；
不过它是⼀个活跃的等待，会浪费⼀些cpu资源。因此如果看到⼤量的⾃旋等待和⾃旋轮转，则很显然它浪费了很多cpu资源。浪费cpu时间和⽆谓的上下⽂切换之间可以
⽤innodb_sync_spin_loops来平衡。
接下来的这段显⽰死锁状况:
1.------------------------
人间中毒迅雷下载2.LATEST DETECTED DEADLOCK
3.------------------------
税源管理4.060717 4:16:48
5.*** (1) TRANSACTION:
6.TRANSACTION 0 42313619, ACTIVE 49 c, process no 10099, OS thread id 3771312 starting index read
8.LOCK WAIT 3 lock struct(s), heap size 320
9.MySQL thread id 30898, query id 100626 localhost root Updating
10.update iz t 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 c, process no 10099, OS thread id 4078512 starting i
ndex read, thread declared inside InnoDB 500
19.3 lock struct(s), heap size 320
20.MySQL thread id 30899, query id 100627 localhost root Updating
21.update iz t 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 最后检测到事务引发的死锁，包括发⽣死锁时的状态，加了什么锁，在等待什么锁释放，以及 Innodb 决定哪个事务会被回滚。注意，innodb只显⽰了事务持有锁的相关简单信息。并且只显⽰了每个事务最后执⾏的语句，发⽣死锁的记录就是由于这些语句引起的。查看复杂的死锁信息还需要查看⽇志⽂件，才能找到真正引发冲突的语句。⼤部分情况下，SHOW INNODB STATUS 显⽰的信息基本⾜够了。
下⾯是关于外键约束引发的死锁信息：
1.------------------------
2.LATEST FOREIGN KEY ERROR
3.------------------------
4.060717 4:29:00 Transaction:
5.TRANSACTION 0 336342767, ACTIVE 0 c, process no 3946, OS thread id 1151088992 inrting, thread declared inside InnoDB 500
7.3 lock struct(s), heap size 368, undo log entries 1
8.MySQL thread id 9697561, query id 188161264 localhost root update
9.inrt 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 clost 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会显⽰引发错误的语句。外键约束定义失败，以及定义关系最密切的⽗表。有很多嵌接信息都
是⽤16进制表⽰，不过对于问题诊断并不是太重要，它们主要⽤于给 Innodb 的开发者来查看或者⽤于调试⽬的。
接下来是显⽰ Innodb 当前活跃的事务：
说明文600字
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 c, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.lect sql_calc_found_rows * from b limit 5
16.Trx read view will not e trx with id>= 0 80157601, es <0 80157597
17.---TRANSACTION 0 80157599, ACTIVE 5 c, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.lect sql_calc_found_rows * from b limit 5
21.Trx read view will not e trx with id>= 0 80157600, es <0 80157596
22.---TRANSACTION 0 80157598, ACTIVE 7 c, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.lect sql_calc_found_rows * from b limit 5
26.Trx read view will not e trx with id>= 0 80157599, es <0 80157595
27.---TRANSACTION 0 80157597, ACTIVE 7 c, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.lect sql_calc_found_rows * from b limit 5
31.Trx read view will not e trx with id>= 0 80157598, es <0 80157594
如果当前连接不是很多，则会显⽰全部事务列表；如果有⼤量连接，则 Innodb 只会显⽰他们的数量，减少输出的列表信息，使得输出结果不会太多。上官体名词解释
