设置了 scanPeriod 之后，过了好长时间，都不生效，后来 debug 代码。发现了下面这段。

  private volatile long mask = 0xF;
@Override
public FilterReply decide(Marker marker, Logger logger, Level level,
String format, Object[] params, Throwable t) {
if (!isStarted()) {
return FilterReply.NEUTRAL;
}
// for performance reasons, skip change detection (MASK-1) times out of MASK.
// Only once every MASK calls is change detection code executed
// Note that MASK is a variable itself.
if (((invocationCounter++) & mask) != mask) {
return FilterReply.NEUTRAL;
}
long now = System.currentTimeMillis();
synchronized (configurationWatchList) {
updateMaskIfNecessary(now);
if (changeDetected(now)) {
// Even though reconfiguration involves resetting the loggerContext,
// which clears the list of turbo filters including this instance, it is
// still possible for this instance to be subsequently invoked by another
// thread if it was already executing when the context was reset.
disableSubsequentReconfiguration();
detachReconfigurationToNewThread();
}
}
return FilterReply.NEUTRAL;
}

这行 if (((invocationCounter++) & mask) != mask) { mask = 0xf，其实要每循环 0xf 次，也就是 15 次，才会去 check 一次是否要更新，也就是说，不管过了多久，如果没到这 15 次，也不会去检查是否更新配置。
也就是说，我多打几次 log，配置文件就生效了。

spring security（下简写为 ss）控制的安全主要有两方面，Web 和 Method Call，这两个方面的权限控制有比较多的相通的设计，也有一些特别的功能。比如 Method Call 可以做 After Invocation 控制，而 Web 可以做 Ip 地址控制。

这里面有两个最基本的概念：authentication manager 和 access decision manager，前者控制认证，后都控制鉴权。
1. 在 ss 的认证系统中，默认的实现帮助我们提供了三个概念，用户（user），角色（authority，一般存 role）和组（group），三者的关系是，组、角色与用户都是多对多关系，组和角色间没关系，默认是不启用组的。后续，在 Acl 权限管理中，可以看到角色之间，是可以有包含（树形？）关系的。
2. 在 ss 的鉴权系统中，明显会比认证复杂得多。有 AccessDecisionManager, AccessDecisionVoter（前置）, AfterInvocationProvider（后置）, RoleHierarchy, SidRetrievalStrategy, LookupStrategy, PermissionGrantingStrategy, SecurityExpressionHandler, AclService, MutableAclService, AclCache 概念过多了，要一个一个解释
a) 中心是 AccessDecisionManager，主要负责 AccessDecisionVoter 的管理，默认提供了3种实现：1. AffirmativeBased 如果有任何一个投票器允许访问,请求将被立刻允许,而不管之前可能有的拒绝决定。2. ConsensusBased 多数票(允许或拒绝)决定了结果，平局的投票 和空票(全是弃权的)的结果是可配置的。3. UnanimousBased 所有的投票器必须全是允许的,否则访问将 被拒绝。
AccessDecisionManager 在用于 Web 和 Method Call 两种情况下，可能是不一致的，因为功能也不一致。
b) Method Call 除了使用 AccessDecisionManager 进行权限判断外，还可以增加 AfterInvocationProvider 来进行出口数据的判断，默认提供了 3 种。
1) PostInvocationAdviceProvider: 需要提供一个 PostInvocationAuthorizationAdvice，默认实现只有一个，就是 ExpressionBasedPostInvocationAdvice，可以通过 spel 来进行权限判断。注意 ExpressionBasedPostInvocationAdvice 中需要提供一个 MethodSecurityExpressionHandler，能够创建出一个 MethodSecurityExpressionOperations，放到 spel context 中，供 spel function 调用，这样的方式，在后续很常见。
2) AclEntryAfterInvocationProvider 和 AclEntryAfterInvocationCollectionFilteringProvider : 这两种都差不多，主要依赖 AclService, ObjectIdentityRetrievalStrategy, SidRetrievalStrategy 来配合，检查返回值的权限。Collection 版本的，可以把无权限的数据去掉，只留下有权限的数据。
c) RoleHierarchy 提供了角色之间的关系，提供了两个实现，一个是没关系的，直接把 user 的 role 返回，另外一个是有继承关系的。继承关系实现挺有意思的，能够处理多级的 include 关系，比较好用。
RoleHierarchy 的使用比较复杂，会被 AccessDecisionVoter, SidRetrievalStrategy, SecurityExpressionHandler 用到，SecurityExpressionHandler 又会被 AccessDecisionVoter 用到，所以还是有点儿混乱。
具体的说 SecurityExpressionHandler 会用到 PermissionEvaluator 和 RoleHierarchy，PermissionEvaluator 的一个实现 AclPermissionEvaluator 会用到 SidRetrievalStrategy。
d) SidRetrievalStrategy 和 RoleHierarchy 的功能比较接近，比 RoleHierarchy 高一个抽象层次，功能上也有所区别，是从一个 authentication 拿到所有相关的 Sid（包括 Role（GrantedAuthoritySid） 和 User（PrincipalSid）），而 RoleHierarchy 只包括了 Role（GrantedAuthoritySid）的继承关系。
e) LookupStrategy 通过 ObjectIdentity 和 Sid 把相关的 Acl 查询出来。可以在 LookupStrategy 扩展 Acl 和 Ace 的功能，比如在 Ace 上面加上时间的条件限制，就需要自己定义 LookupStrategy，把时间条件从数据库查询出来，并放到自定义的 Ace 当中。
但这件事情非常麻烦，因为默认实现的 BasicLookupStrategy 是个 Final 的类，所以只能自己直接实现接口，无法使用现有的功能。
LookupStrategy 会生成 Acl，而最终的权限验证是由 Acl 完成的，如果想验证带时间条件的 Ace，需要给 Acl 设置自定义的带有检查时间功能的 PermissionGrantingStrategy，实际上，这个 PermissionGrantingStrategy 会首先设置给 LookupStrategy，LookupStrategy 在创建 Acl 的时候，再放到 Acl 中去。
f) SecurityExpressionHandler 能够执行 spel，得到是否可以访问的结果，它的子类都是继承自 AbstractSecurityExpressionHandler 的，有一个非常重要的方法是 SecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, T invocation)，创建一个 SecurityExpressionOperations 放到 EvaluationContext 中去，提供 spel 中执行的方法实现。比如 SecurityExpressionOperations 的一个抽象实现 SecurityExpressionRoot 中，就包含了大量的权限验证方法，如 hasRole, hasPermission 等常用的功能。
g) AclService, MutableAclService, AclCache 概念比较简单，AclService 是通过 LookupStrategy 查询 Acl，自已可以查询 ObjectIdentity 的父子关联关系，MutableAclService 提供了修改的能力，AclCache 为 AclService 提供缓存，默认的实现了一个 EhCacheBasedAclCache。
3. ss 的鉴权模型 Sid, ObjectIdentity, Acl, Ace, Permission
a) Sid: 是中心，所有的授权会关联在 Sid 上面，Sid 和之前的 Role Base Permission 会有些相同的地方，但也明显不同，Sid 默认实现情况下，分为 GrantedAuthoritySid 和 PrincipalSid，其实就是 Role 和 User，通过 SidRetrievalStrategy 拿到一个 Authentication 的 Sid。
b) ObjectIdentity: 可以理解成 Resource，就是可访问的目标资源，有 id 和 type 两个字段，默认实现的 ObjectIdentityImpl 会直接调用目标 domainObject 的 getClass 和 getId 方法拿到两个参数。在 PermissionEvaluator, AfterInvocationProvider 中，会用到 ObjectIdentityRetrievalStrategy 和 ObjectIdentityGenerator，ObjectIdentityRetrievalStrategy 会根据 domainObject 拿到 ObjectIdentity，然后使用 Acl 进行鉴权，ObjectIdentityGenerator 会在系统提供的不是 domainObject，而是 type, id 的时候，拿到 ObjectIdentity，然后进行 Acl 鉴权，这两个接口有一个共同的实现 ObjectIdentityRetrievalStrategyImpl，如果需要在 ObjectIdentity 进行新的抽象，需要用新的实现，到得不同的 ObjectIdentity，比如将业务对象分类鉴权这样的需求。
c) Acl, 每个 ObjectIdentity 最多对应一条 Acl，Acl 中包含了很多，包括 parental，说明 Acl 是有继承关系的？其实不是，呵呵，是 ObjectIdentity 有继承关系而已。有一个 ObjectIdentity，有很多 Sid，还有一个叫做 Owner 的 Sid，有从 LookupStrategy 传过来的 PermissionGrantingStrategy，进行实际的鉴权，还有 AclAuthorizationStrategy 检查有没有权限进行 Acl security check。实现时间条件检查，就扩展 PermissionGrantingStrategy。
为什么没有 RoleHierarchy 或是 SidRetrievalStrategy 存在呢？是因为调用 Acl 进行权限检查之前，已经把相关的 Sid 得到了，再给 Acl 的。
d) Ace, Permission: Ace 存储 Sid, Permission，提供给 Acl 鉴权用。增加时间条件的话，最基本的，就是要在 Ace 中，增加时间条件字段。Permission 是用二进制存储的，但默认实现的数据库存储并不是，是一个一条，存在数据库里面的。

好吧，概念还是非常多的，不过鉴于权限控制本身就是个复杂的话题，ss 这些设计的我觉得已经非常好，也基本够用了。

主要完成了下面4个工作

1. 创建一个本地的目录结构，以存放 rpm 包
2. 启动一个 apache，使这些文件能够远程访问
3. 写一个 spec，并且用 rpmbuild 做成一个安装包，用来在机器上安装新的 repository 位置
4. 使用 yum downloadonly plugin 将需要的 rpm 包放到本地目录下，然后使用 createrepo 命令创建 metadata

本来是希望能有一个类似于 nexus 这样的 proxy host server 将远程的 package cache 下来，找来找去，也找到了一个 nexus yum plugin，但这个 plugin 只支持手工的 deploy rpm package 到 nexus 上面，不能做 proxy 方式的。

写写步骤和遇到的问题吧。

准备工作

• 安装 createrepo, yum install createrepo
• 安装 yum download only plugin, yum -y install yum-downloadonly
• 安装 rpmbuild, yum -y install rpm-build
• 确认已经安装了 apache nginx 之类的 http server

服务器步骤

• 首先是创建目录结构，比如 mkdir -p /data/yum/centos/6/x86_64
• 先增加 chef 的源，rpm -Uvh http://rbel.frameos.org/rbel6
• 然后是通过 yum -y install rubygem-chef-server –downloadonly –downloaddir=/data/yum/centos/6/x86_64
• 这时，已经可以去掉 chef 的公共源了，rpm -e rbel6-release
• 创建本地库的 metadata，createrepo /data/yum/centos/6/x86_64，还有一些参数可用，比如 -p, pretty xml, -d create sqlite database files
• 配置 apache，修改 /etc/httpd/conf/httpd.conf，修改 DocumentRoot 和 Directory 位置，改为 /data，并启动 httpd -k start，也可以使用 chkconfig –level 3 https on，每次开机启动

客户端步骤

• 首先要制作安装 repository 位置的 rpm 包
• 创建文件 haha.repo，放到 /root/rpmbuild/SOURCES 目录下，这个是将来 copy 到客户端的 /etc/yum.repos.d/ 目录下的配置文件，内容为

  [haha]
      name=haha
      baseurl=http://192.168.157.131/yum/centos/$releasever/$basearch/
      enabled=1
      gpgcheck=0

• 再创建文件 build spec 文件，放到 /root/rpmbuild/SOURCES 目录下，是为了创建 rpm 包用的，haha.spec

  Summary:       haha
      Name:          haha
      Version:       0.1
      Release:       1
      Source0:       haha
      Group:         Applications/Internet
      License:       GPLv2+
      URL:           http://192.168.157.131/yum/
      #BuildRoot:     %{_tmppath}/%{name}-%{version}-root
      BuildArch:     noarch
  
      %description
      The haha yum repo
      #%prep
      #%setup -q
      %install
      mkdir -p $RPM_BUILD_ROOT/etc/yum.repos.d
      install -m 0644 -p %{SOURCE0} $RPM_BUILD_ROOT/etc/yum.repos.d
  
      %clean
      rm -rf ${RPM_BUILD_ROOT}
      %files
      /etc/yum.repos.d/haha.repo

• 使用 rpmbuild -ba haha.spec，做出一个 rpm 包，位置在 /root/rpmbuild/RPMS/noarch 下面
• 制作一次 rpm 后，就可以一直使用了，rpm -ivh xxx.rpm 就可以了

参考了
1. 自建yum源与制作RPM安装包yum源
2. yum只下载rpm包不自动安装方法
3. Installing Chef Server 0.10 in RHEL 6

stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);

在 Eclipse 中执行下面代码。

        byte[] bytes = new byte[]{-16, -97, -116, -70};

        String s = new String(bytes, "UTF-8");

        System.out.println(s);

结果打印出了一朵花，呵呵，实在是太有意思了。

http://en.wikipedia.org/wiki/Category:Unix_signals 1.SIGHUP信号 UNIX中进程组织结构为 session (会话)包含一个前台进程组及一个或多个后台进程组，一个进程组包含多个进程。一个session可能会有一个session首进程，而一个session首进程可能会有一个控制终端。一个进程组可能会有一个进程组首进程。进程组首进程的进程ID与该进程组ID相等。这儿是可能会有，在一定情况之下是没有的。与终端交互的进程是前台进程，否则便是后台进程。 SIGHUP会在以下3种情况下被发送给相应的进程： 1、终端关闭时，该信号被发送到session首进程以及作为job提交的进程（即用 & 符号提交的进程） 2、session首进程退出时，该信号被发送到该session中的前台进程组中的每一个进程 3、若父进程退出导致进程组成为孤儿进程组，且该进程组中有进程处于停止状态（收到SIGSTOP或SIGTSTP信号），该信号会被发送到该进程组中的每一个进程。 系统对SIGHUP信号的默认处理是终止收到该信号的进程。所以若程序中没有捕捉该信号，当收到该信号时，进程就会退出。 下面观察几种因终端关闭导致进程退出的情况，在这儿进程退出是因为收到了SIGHUP信号。login shell是session首进程。 首先写一个测试程序，代码如下： #include <stdio.h> #include <signal.h> char **args; void exithandle(int sig) {         printf("%s : sighup received ",args[1]); } int main(int argc,char **argv) {         args = argv;         signal(SIGHUP,exithandle);         pause();        return 0; } 程序中捕捉SIGHUP信号后打印一条信息，pause()使程序暂停。 编译后的执行文件为sigtest。 1、命 令：sigtest front > tt.txt    操 作：关闭终端    结 果：tt.txt文件的内容为front : sighup received    原 因: sigtest是前台进程，终端关闭后，根据上面提到的第1种情况，login shell作为session首进程，会收到SIGHUP信号然后退出。根据第2种情况，sigtest作为前台进程，会收到login shell发出的SIGHUP信号。 2、命 令：sigtest back > tt.txt &      操 作：关闭终端       结 果：tt.txt文件的内容为 back : sighup received       原 因: sigtest是提交的job，根据上面提到的第1种情况，sigtest会收到SIGHUP信号。 3、命 令：写一个shell，内容为[sigtest &]，然后执行该shell       操 作：关闭终端       结 果：ps -ef | grep sigtest 会看到该进程还在，tt文件为空       原 因: 执行该shell时，sigtest作为job提交，然后该shell退出，致使sigtest变成了孤儿进程，不再是当前session的job了，因此sigtest即不是session首进程也不是job，不会收到SIGHUP。同时孤儿进程属于后台进程，因此login shell退出后不会发送SIGHUP给sigtest，因为它只将该信号发送给前台进程。第3条说过若进程组变成孤儿进程组的时候，若有进程处于停止状态，也会收到SIGHUP信号，但sigtest没有处于停止状态，所以不会收到SIGHUP信号。 4、命 令：nohup sigtest > tt       操 作：关闭终端       结 果：tt文件为空       原 因: nohup可以防止进程收到SIGHUP信号 至此，我们就清楚了何种情况下终端关闭后进程会退出，何种情况下不会退出。 要想终端关闭后进程不退出有以下几种方法，均为通过shell的方式： 1、编写shell，内容如下        trap "" SIGHUP #该句的作用是屏蔽SIGHUP信号，trap可以屏蔽很多信号       sigtest 2、nohup sigtest 可以直接在命令行执行，        若想做完该操作后继续别的操作，可以 nohup sigtest & 3、编写shell，内容如下        sigtest &        其实任何将进程变为孤儿进程的方式都可以，包括fork后父进程马上退出。 2.SIGCHLD信号        子进程死后,会发送SIGCHLD信号给父进程。         一个进程在调用exit命令结束自己的生命的时候，其实它并没有真正的被销毁，而是留下一个称为僵尸进程（Zombie）的数据结构（系统调用exit，它的作用是使进程退出，但也仅仅限于将一个正常的进程变成一个僵尸进程，并不能将其完全销毁）。在Linux进程的状态中，僵尸进程 是非常特殊的一种，它已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集，除此之外，僵尸进程不再占有任何内存空间。它需要它的父进程来为它收尸，如果他的父进程没安装SIGCHLD信号处理函数调用wait或waitpid()等待子进程结束，又没有显式忽略该信号，那么它就一直保持僵尸状态，如果这时父进程结束了，那么init进程自动会接手这个子进程，为它收尸，它还是能被清除的。但是如果如果父进程是一个循环，不会结束，那么子进程就会一直保持僵尸状态，这就是为什么系统中有时会有很多的僵尸进程。 2.SIGTERM信号 kill() 可以发 SIGTERM 过去；kill 命令默认也使用 SIGTERM 信号。 SIGTERM 信号的处理函数，常见的是用来清理、退出；或者程序可以忽略这个信号，以防误杀。         SIGTERM is the default signal sent to a process by the kill or killall commands. It causes the termination of a process, but unlike the SIGKILLsignal, it can be caught and interpreted (or ignored) by the process. Therefore, SIGTERM is more akin to asking a process to terminate nicely, allowing cleanup and closure of files. For this reason, on many Unix systems during shutdown, init issues SIGTERM to all processes that are not essential to powering off, waits a few seconds, and then issues SIGKILL to forcibly terminate other processes to allow the computer to halt.

$ kill -l

            1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL

            5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE

            9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2

            13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGSTKFLT 17) SIGCHLD

            18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN

            22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ

            26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO

            30) SIGPWR      31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1

            36) SIGRTMIN+2  37) SIGRTMIN+3  38) SIGRTMIN+4  39) SIGRTMIN+5

            40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8  43) SIGRTMIN+9

            44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13

            48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13

            52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9

            56) SIGRTMAX-8  57) SIGRTMAX-7  58) SIGRTMAX-6  59) SIGRTMAX-5

            60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2  63) SIGRTMAX-1

            64) SIGRTMAX

 patch.sh.zip (1 K) 下载次数:103 

转自：http://blog.csdn.net/cafecheng/archive/2009/07/17/4357248.aspx

H2, HSQLDB, DERBY, POSTGRESQL, MYSQL

转自 http://imysql.cn/node/609

作/译者：吴炳锡，来源：http://imysql.cn　＆　http://imysql.cn/blog/3208　转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

介绍：
InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。
Innodb 的创始人：Heikki Tuuri
Heikki Tuuri在Ｉｎｎｏｄｂ的Ｂｕｇ社区里也是很活跃的，如果遇到Ｂｕｇ也可以直接提到社区，得到作者的解答。

为什么要学习Ｉｎｎｏｄｂ的调优：
目前来说：InnoDB是为Mysql处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。
另一方面，在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。

参数调优内容：
　　1. 内存利用方面
2. 日值控制方面
3.　文件IO分配，空间占用方面
4. 其它相关参数

１.内存利用方面：
首先介绍一个Innodb最重要的参数：
innodb_buffer_pool_size
这个参数和MyISAM的key_buffer_size有相似之处，但也是有差别的。这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。为Innodb加速优化首要参数。
该参数分配内存的原则：这个参数默认分配只有8M，可以说是非常小的一个值。如果是一个专用ＤＢ服务器，那么他可以占到内存的70%-80%。这个参数不能动态更改，所以分配需多考虑。分配过大，会使Swap占用过多，致使Mysql的查询特慢。如果你的数据比较小，那么可分配是你的数据大小＋１０％左右做为这个参数的值。例如：数据大小为５０Ｍ,那么给这个值分配innodb_buffer_pool_size＝６４Ｍ
设置方法：
innodb_buffer_pool_size=4G
这个参数分配值的使用情况可以根据show innodb status\G;中的
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894; 
去确认使用情况。

第二个：
innodb_additional_mem_pool：
作用：用来存放Innodb的内部目录
这个值不用分配太大，系统可以自动调。不用设置太高。通常比较大数据设置16Ｍ够用了，如果表比较多，可以适当的增大。如果这个值自动增加，会在error log有中显示的。
分配原则：
用show innodb status\G;去查看运行中的ＤＢ是什么状态（参考BUFFER POOL AND MEMORY段中），然后可以调整到适当的值。
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894; in additional pool allocated 16777216
参考：in additional pool allocated 16777216
根据你的参数情况，可以适当的调整。
设置方法：
innodb_additional_mem_pool=16M

２.关于日值方面：
innodb_log_file_size
作用：指定日值的大小
分配原则：几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个ＬＯＧ文件相加大小在２Ｇ以内为佳。具体情况还需要看你的事务大小，数据大小为依据。
说明：这个值分配的大小和数据库的写入速度，事务大小，异常重启后的恢复有很大的关系。
设置方法：
innodb_log_file_size=256M

innodb_log_files_in_group
作用：指定你有几个日值组。
分配原则：　一般我们可以用２－３个日值组。默认为两个。
设置方法：
innodb_log_files_in_group=3

innodb_log_buffer_size：
作用：事务在内存中的缓冲。
分配原则：控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Ｏｒａｃｌｅ等数据库了解这个，一般最大指定为３Ｍ比较合适。
参考：Innodb_os_log_written(show global status 可以拿到)
如果这个值增长过快，可以适当的增加innodb_log_buffer_size
另外如果你需要处理大理的ＴＥＸＴ，或是ＢＬＯＢ字段，可以考虑增加这个参数的值。
设置方法：
innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit
作用：控制事务的提交方式
分配原则：这个参数只有３个值，０，１，２请确认一下自已能接受的级别。默认为１，主库请不要更改了。
性能更高的可以设置为０或是２，但会丢失一秒钟的事务。
说明：
这个参数的设置对Ｉｎｎｏｄｂ的性能有很大的影响，所以在这里给多说明一下。
当这个值为1时：innodb 的事务LOG在每次提交后写入日值文件，并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。
当这个值为2时：在每个提交，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的是，由于进程调用方面的问题，并不能保证每秒１００％的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。
当这个值为0时：日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

从以上分析，当这个值不为１时，可以取得较好的性能，但遇到异常会有损失，所以需要根据自已的情况去衡量。

设置方法：
innodb_flush_logs_at_trx_commit=1

3.　文件IO分配，空间占用方面
innodb_file_per_table
作用：使每个Innodb的表，有自已独立的表空间。如删除文件后可以回收那部分空间。
分配原则：只有使用不使用。但ＤＢ还需要有一个公共的表空间。
设置方法：
innodb_file_per_table=1

innodb_file_io_threads
作用：文件读写ＩＯ数，这个参数只在Windows上起作用。在LINUX上只会等于４
设置方法：
innodb_file_io_threads=4

innodb_open_files
作用：限制Innodb能打开的表的数据。
分配原则：如果库里的表特别多的情况，请增加这个。这个值默认是３００。
设置方法：
innodb_open_files=800 
请适当的增加table_cache

4. 其它相关参数
这里说明一个比较重要的参数：
innodb_flush_method
作用：Ｉｎｎｏｄｂ和系统打交道的一个ＩＯ模型
分配原则：Windows不用设置。
Ｕｎｉｘ可以设置：fsync() or O_SYNC/O_DSYNC
如果系统可以禁止系统的Ｃａｃｈｅ那就把他禁了。
Ｌｉｎｕｘ可以选择：O_DIRECT 
直接写入磁盘，禁止系统Ｃａｃｈｅ了
设置方法：
innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct 
作用：控制Innodb的脏页在缓冲中在那个百分比之下，值在范围1-100,默认为90.
这个参数的另一个用处：当Ｉｎｎｏｄｂ的内存分配过大，致使Ｓｗａｐ占用严重时，可以适当的减小调整这个值，使达到Ｓｗａｐ空间释放出来。建义：这个值最大在９０％，最小在１５％。太大，缓存中每次更新需要致换数据页太多，太小，放的数据页太小，更新操作太慢。
设置方法：
innodb_max_dirty_pages_pct＝90
动态更改需要有Ｓｕｐｅｒ权限：
set global innodb_max_dirty_pages_pct=50;

总结：
这里只算是列出了Ｉｎｎｏｄｂ部分的重要参数，不能认为是对Ｍｙｓｑｌ的整体调优。Ｍｙｓｑｌ的参数一般分为：全局参数，具体引擎的参数。全局参数方面请参考http://imysql.cn/2007_12_08_optimize_mysql_under_linux yejr的那个Ｍｙｓｑｌ调优的ＰＰＴ。

• innodb_monitor：create table innodb_monitor(x int) engine=innodb;
• innodb_lock_monitor：create table innodb_lock_monitor(x int) engine=innodb;
• innodb_table_monitor：create table innodb_table_monitor(x int) engine=innodb;
• innodb_tablespace_monitor：create table innodb_tablespace_monitor(x int) engine=innodb;

=====================================
090805 22:24:48 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 19 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 312921, signal count 308229
Mutex spin waits 0, rounds 18209349, OS waits 111906
RW-shared spins 287775, OS waits 142204; RW-excl spins 175036, OS waits 19318
------------
TRANSACTIONS
------------
Trx id counter 0 121675664
Purge done for trx's n:o < 0 121675662 undo n:o < 0 0
History list length 10
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 121462143, not started, process no 8452, OS thread id 1160767840
mysql tables in use 1, locked 1
MySQL thread id 8056144, query id 78206864 localhost root
---TRANSACTION 0 137229, not started, process no 8452, OS thread id 1158199648
MySQL thread id 50, query id 377 Has read all relay log; waiting for the slave I/O thread to update it
--------
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: 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
34 OS file reads, 80820900 OS file writes, 1263117 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 1.16 writes/s, 0.63 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 8850487, node heap has 233 buffer(s)
0.11 hash searches/s, 0.42 non-hash searches/s
---
LOG
---
Log sequence number 4 3697502095
Log flushed up to   4 3697502095
Last checkpoint at  4 3697502095
0 pending log writes, 0 pending chkp writes
79595438 log i/o's done, 0.47 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4851752298; in additional pool allocated 13195520
Dictionary memory allocated 145784
Buffer pool size   262144
Free buffers       193334
Database pages     68577
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 70, created 120513, written 2829967
0.00 reads/s, 0.21 creates/s, 0.84 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 8452, id 1157658976, state: waiting for server activity
Number of rows inserted 12233742, updated 57497659, deleted 1, read 69720050
0.05 inserts/s, 0.05 updates/s, 0.00 deletes/s, 0.05 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

===========================================
090805 22:26:56 INNODB TABLE MONITOR OUTPUT
===========================================
--------------------------------------
TABLE: name SYS_FOREIGN, id 0 11, columns 7, indexes 3, appr.rows 0
COLUMNS: ID: DATA_VARCHAR prtype 1835012 len 0; FOR_NAME: DATA_VARCHAR prtype 1835012 len 0;
REF_NAME: DATA_VARCHAR prtype 1835012 len 0; N_COLS: DATA_INT len 4;
DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR:
DATA_SYS prtype 258 len 7;   INDEX: name ID_IND, id 0 11, fields 1/6, uniq 1, type 3
root page 46, appr.key vals 0, leaf pages 1, size pages 1
FIELDS:  ID DB_TRX_ID DB_ROLL_PTR FOR_NAME REF_NAME N_COLS
INDEX: name FOR_IND, id 0 12, fields 1/2, uniq 2, type 0
root page 47, appr.key vals 0, leaf pages 1, size pages 1
FIELDS:  FOR_NAME ID
INDEX: name REF_IND, id 0 13, fields 1/2, uniq 2, type 0
root page 48, appr.key vals 0, leaf pages 1, size pages 1
FIELDS:  REF_NAME ID
...省略若干输出
--------------------------------------
TABLE: name test/test, id 0 81, columns 4, indexes 1, appr.rows 3
COLUMNS: i: DATA_INT DATA_BINARY_TYPE len 4; DB_ROW_ID: DATA_SYS prtype 256 len 6;
DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
INDEX: name GEN_CLUST_INDEX, id 0 23, fields 0/4, uniq 1, type 1
root page 3, appr.key vals 3, leaf pages 1, size pages 1
FIELDS:  DB_ROW_ID DB_TRX_ID DB_ROLL_PTR i
-----------------------------------
END OF INNODB TABLE MONITOR OUTPUT
==================================

================================================
090805 22:28:16 INNODB TABLESPACE MONITOR OUTPUT
================================================
FILE SPACE INFO: id 0
size 65536, free limit 6208, free extents 89
not full frag extents 6: used pages 69, full frag extents 0
first seg id not used 0 1067667
SEGMENT id 0 1067666 space 0; page 903; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
...省略若干输出
SEGMENT id 0 144216 space 0; page 1307; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
NUMBER of file segments: 37
Validating tablespace
Validation ok
---------------------------------------
END OF INNODB TABLESPACE MONITOR OUTPUT
=======================================

转自MySQL 中文网：http://imysql.cn/2008_05_22_walk_through_show_innodb_status
感谢两个作者，呵呵

原文作者： Peter Zaitsev
原文来源： http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/
译者：叶金荣（Email:），转载请注明译者和出处，并且不能用于商业用途，违者必究。

很多人让我来阐述一下 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 second averages calculated from the last 44 seconds

首先要确认这是至少统计了 20-30 秒的样本数据。如果平均统计间隔是0或1秒，那么结果就没什么意义了。
说实在的我不喜欢InnoDB提供的平均值，因为很难取得合理的平均间隔统计值，如果你是写脚本来取得 SHOW INNODB STATUS 结果的话，那么最好取得全局的统计结果，然后取得平均值。当然了，直接查看输出的结果信息也是很有用的。

下一部分显示了信号(Semaphores)相关信息：

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个部分。一部分是当前的等待，这部分只是包含了在高并发环境下的全部记录，因此 InnoDB 会频繁回退到系统等待。如果等待是通过自旋锁来解决的话，那么这些信息就就不会显示了。

通过这部分信息，你就会知道系统负载的热点在哪了。不过这需要了解一下源码相关的知识 - 从上面的信息中就可以看出来是哪个源码文件中的哪行(不同的版本结果可能不同)，只是从这里却看不出来任何信息。尽管如此，还是可以从文件名中猜到一些东西 - 比如本例中，文件名 "buf0buf.ic" 预示着和一些缓冲池争夺有关系。如果想了解更多，就去看源码吧。

还有一些关于等待的更多细节。"lock var" 表示当前的 mutex 对象的值(被锁住 = 1 / 释放 = 0) 值，"waiters flag" 表示当前的等待个数。另外，本例中还可以看到等待状态信息 "wait is ending"，这表示 mutex 已经释放，但是系统调度线程还正在处理。

第二块是事件统计 - "reservation count" 和 "signal count" 显示了 innodb 使用内部同步阵列的活跃程度 - 时间片(slot)分配以及线程信号使用同步阵列的频繁程度。这些统计信息可以用于表示 innodb 回退到系统等待的频率。还有关于系统等待的直接相关信息，可以看到"OS Waits"的互斥信号灯(mutexes)，以及读写锁。这些信息中显示了互斥锁和共享锁。系统等待和 "保留(reservation)" 不完全一样，在回退到用 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 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 最后检测到事务引发的死锁，包括发生死锁时的状态，加了什么锁，在等待什么锁释放，以及 Innodb 决定哪个事务会被回滚。注意，innodb只显示了事务持有锁的相关简单信息。并且只显示了每个事务最后执行的语句，发生死锁的记录就是由于这些语句引起的。查看复杂的死锁信息还需要查看日志文件，才能找到真正引发冲突的语句。大部分情况下，SHOW INNODB STATUS 显示的信息基本足够了。

下面是关于外键约束引发的死锁信息：

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会显示引发错误的语句。外键约束定义失败，以及定义关系最密切的父表。有很多嵌接信息都是用16进制表示，不过对于问题诊断并不是太重要，它们主要用于给 Innodb 的开发者来查看或者用于调试目的。

接下来是显示 Innodb 当前活跃的事务：

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

如果当前连接不是很多，则会显示全部事务列表；如果有大量连接，则 Innodb 只会显示他们的数量，减少输出的列表信息，使得输出结果不会太多。

事务ID是当前事务的标识，事务的id每次都会增加。Purge done for trx's n:o 是指净化(purge)线程已经完成的事务数。Innodb仅清除那些被当前事务认为不再需要的旧版本数据。那些未提交的旧事务可能会阻塞净化线程并且消耗资源。通过查看2次清除事务数之差，就可以知道是否发生了这种情况。少数情况下，净化线程可能难以跟上更新的速度，2次查看值之差可能会越来越大；那么，innodb_max_purge_lag 就派得上用场了。 "undo n:o" 显示了净化线程当前正在处理的回滚日志号，如果当前不处于活跃状态，则它的值是 0。

History list length 6 是指在回滚空间中的未清除事务数。随着事务的提交，它的值会增加；随着清除线程的运行，它的值会减小。

Total number of lock structs in row lock hash table 是指事务分配过的行锁结构总数。它和曾经被锁住过的行总数不一定相等，通常是一个锁结构对应多行记录。

MySQL中，每个连接如果没有活动的事务，则它的状态是 not started，如果有活动的事务，则是 ACTIVE。注意，尽管事务是活动的，但是其连接的状态却可能是 "睡眠(sleep)" - 如果是在一个有多条语句的事务里的话。Innodb 会同时显示系统的线程号以及进程号，这有助于利用gdb来调试或者其他类似用途。另外，事务的状态也会根据当前实际状态来显示，例如 "读取记录(fetching rows)"，em>"更新(updating)"等等。"Thread declared inside InnoDB 400" 的意思是 Innodb 内核正在运行该线程，并且还需要400个票。Innodb 会根据 innodb_thread_concurrency 的值来限制同时并发的线程数不超过它。如果线程当前不在 Innodb 的内核中运行，则它的状态可能是 "waiting in InnoDB queue" 或 "sleeping before joining InnoDB queue"。后面这个状态有点意思 - Innodb 为了避免有太多的线程同时抢着要进入运行队列，那么就会尝试让这些线程进入等待状态(如果没有足够的空闲插槽(slot)的话)。这就可能会导致 Innodb 内核中当前活跃的线程数可能比innodb_thread_concurrency 的值还小。某种负载环境下，这可能有助于减小线程进入队列的时间。可以通过调整 innodb_thread_sleep_delay 来实现，它的单位是微妙。

mysql tables in use 1, locked 0 是指事务中已经用过的数据表个数(已经访问过了的)，以及被锁的个数。Innodb 一般情况不会锁表，因此锁表数一般是0，除非是ALTER TABLE 或者其他类似 LOCK TABLES 的语句。

除了Innodb相关的特定信息外，一些基本信息可以通过 来查看，例如正在执行什么语句，查询ID号，查询状态等。

下面这部分显示的是跟IO相关的具体信息：

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助手线程状态 - 插入缓冲线程，日志线程，读、写线程。它们分别对应插入缓冲合并，异步日志刷新，预读以及刷新脏数据。源自查询的正常读取是由正在运行的查询执行的。在Unix/Linux平台下，总能看见4个线程，在Windows上可以通过 innodb_file_io_threads 来调整。每个线程准备好之后都能看到其状态：waiting for i/o request 或者正在执行特定的操作。

每个线程都会显示正在进行的操作数量 - 同时正要执行或者正在执行的操作数量。另外，正在执行的 fsync 操作数量也会显示出来。有写数据时，Innodb需要确保数据最终被写到磁盘上，只是把它们放在系统缓存里是不够的。通常是调用 fsync() 来完成的。如果它的值一直很高，那意味这Innodb可能是处于IO负载较高状态。注意，由线程执行请求引发的IO请求是不计算在内的，因此尽管系统的IO负载较高，但是它们的值却可能为 0。

接下来显示的是IO操作的平均统计值，它们对于图形显示或者监控很有用。
"16384 avg bytes/read" 是读请求的平均值。随机IO的话，每个页的大小是16K，全表扫描或索引扫描时的预读会导致这个值明显的增加。因此，它体现了预读的效率。

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

本部分显示了插入缓冲以及自适应哈希索引的状态。第一行显示了插入缓冲的状态 - 段的大小以及空闲列表，以及缓冲中有多少记录。接下来显示了缓冲中已经完成了多少次插入，有多少记录已经合并，有多少次合并已经完成。合并次数除以插入次数得到的比率可以反映出插入缓冲的效率如何。

Innodb采用哈希索引建立内存页索引形成自适应哈希索引而不是采 B-tree 索引，得以加速行记录到内存页的检索。这里显示了哈希表的大小，以及自适应哈希索引使用了多少单元和缓冲。可以通过计算利用哈希索引检索的次数以及没利用它检索的次数来了解哈希索引的效率。

当前对自适应哈希索引基本没有什么办法可以调整它，主要还是用于查看。

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

接下来显示的是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.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

这部分显示了缓冲池和内存的利用率相关信息。可以看到Innodb分配的所有内存(有些时候可能比你设置的还要多点)，以及额外的内存池分配情况(可以检查它的大小是否正好)，缓冲池总共有多少个内存页，有多少空闲内存页，数据库分配了多少个内存页以及有多少个脏内存页。从这些信息中，就可以判断内存缓冲池是否设定合理，如果总是有大量空闲内存页，则不需要设置那么多内存，可以适当减小一点。如果空闲内存页为 0，这种情况下数据库内存页就不一定会和缓冲池的总数一致，因为缓冲池还需要保存锁信息，自适应哈希索引以及其他系统结构等信息。

等待中的读写是指内存缓冲池级别的请求。Innodb可能会把多个文件级别的请求合并到一个上，因此各不相同。我们还可以看到Innodb提交的各种不同类型的IO，LRU内存页中需要刷新的页 - 脏内存页，它们不会被长时间存取；刷新列表 -
检查点进程处理完之后需要刷新的旧内存页；独立内存页 - 独立的写内存页。

我们还可以看到内存页总共读写了多少次。已经创建的内存页是当前一个内存页中的内容没有读取到内存缓冲池中时，专门为新数据创建的空内存页。

最后我们可以看到缓冲池的命中率，它预示着缓冲池的效率。1000/1000 相当于 100% 的命中率。不过这样也很难说明缓冲池的命中率就足够高了，这要需要根据不同的负载环境而定。通常情况下，950/1000 就够了，有些时候在IO负载较高的环境下，命中率可能为 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

最后一部分，显示了数据行操作以及一些系统信息相关情况。

一开始显示了Innodb线程队列状态 - 有多少线程处于等待或活跃的。Innodb内部打开了多少读视图 -
这是在事务开始后，但是当前还没有活跃语句的情况，Innodb主线程的状态控制了系统操作调度的数量 - 刷新脏内存页、检查点、净化线程、刷新日志、合并插入缓冲等。 "state" 的值则表示了主线程当前的状态。

接下来可以看到自从系统启动以来，所有的数据行操作数量及其平均值。它们可以很方便地用于监控以及画出系统状态图，数据行操作次数可以很好的衡量Innodb的负载。不是所有的数据行操作带来的负载都是一样的，存取10字节的行比10Mb的行相比会小了很多，不过相对于查询的总次数来说这个信息可是有用的多了，差别也很大。

还有一点需要注意的是，SHOW INNODB STATUS 不是一成不变的，有些时间点上可能会不相符。SHOW INNODB STATUS结果中，不同时间可能会显示不同结果，因此有些时候可能会看到冲突的信息。这是由于设计时需要由全局锁提供一致性信息，导致了大量的开销。