3.?InnoDB日志
3.1.?Innodb_log_buffer_size
3.1.1.?不要设置超过2-9M，除非你使用大量的超大文件，日志文件都会被刷新在每秒执行完毕后。
3.1.2.?检查innodb_os_log_written的增长来看你的日志文件的写入。
3.1.3.?Innodb日志是物理逻辑的，不是基于页的，所以他们是非常紧凑的。
3.2.?Innodb_flush_logs_at_trx_commit
3.2.1.?默认日志被刷新到磁盘上在每次事务提交后。这个是为了保证ACID（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）），所以开销非常大。
3.2.2.?可以设置2和0，如果你能接受丢失最后一次的事务。
4.?InnoDB日志重新设置大小
4.1.?这个不是简单修改选项和重启下能够完成的。
4.2.?首先要关闭MysQL服务器
4.3.?确认它是正常关闭的（检查有没有错误日志）
4.4.?移动所有InnoDB日志文件到其它地方
4.5.?修改配置文件然后重新启动MySQL服务器
4.6.?检查错误日志并查看是否产生新的日志文件。
5.?InnoDB_flush_method
5.1.?指定一个方法让innodb跟OS文件系统一起工作
5.2.?Windows:?总是使用没有buffer的IO方法
5.3.?Unix:可以使用fsync()或者O_SYNC/O_DSYNC进行刷新文件。
5.3.1.?Fsync()通常是更快的，允许累计多个写操作然后并发执行。
5.3.2.?一些操作系统允许关闭OS级别的缓冲针对InnoDB的数据文件。这样非常好，你总不希望数据被缓冲2次吧。
5.4.?Linux：O_DIRECT?使用直接的非缓冲IO。避免双重缓冲，可能会让写更慢。
6.?Innodb_file_per_table
6.1.?InnoDB可以存储每个表在单独的文件中。
6.2.?对于系统需要的主表空间还是需要的。
6.3.?能够帮助拆封不同的表到多个磁盘上。
6.4.?如果表被删除允许回收空间。
6.5.?有时候使用连续的fsync()写会更慢。
6.6.?当有大量的表的时候会增加启动和关闭的时间。
7.?其它文件IO设定
7.1.?Innodb_autoextend_increment–这个参数指定了对于共享表空间的增量（不是为了单独表空间的）。大的值可以有效的减少碎片。
7.2.?Innodb_file_io_thread–改变IO线程的数量，只对windows有效，所有4个线程可以做不同的事情。
7.3.?Innodb_open_file–这个值是用作指定每个表空间所允许打开文件的数量。如果你有很多表那就要增加它。
7.4.?Innodb_support_x–把这个值设置定为0的时候能够减少innodb的工作在事务提交时。Binlog?能够通过异步的方式同步。
8.?最小化重启时间
8.1.?Innodb缓存池可能有一些未写入到磁盘的数据。所以关闭的时候需要非常的时间。
8.2.?如果你想最小化关闭时间，那需要如下设定：
8.2.1.?SET?GLOBAL?innodb_max_dirty_pages_pct=0
8.2.2.?执行show?status后观察?innodb_buffer_pool_pages_dirty
8.2.3.?当这个值变为0的时候就可以关闭服务器了
8.3.?在执行这个操作时候会让性能降低，因为InnoDB将立刻要将脏数据页写入到磁盘上。
9.?排错逃离清除
9.1.?InnoDB不会通过delete来移除一行（和在更新时候旧的行），因为这些行可能会被其他事务使用。
9.2.?清除线程被用在清除这些没有用到的行。
9.3.?在一些工作负载，清除线程可能不能保持这些表空间无限的增长。通过show?innodb?status观察transactions部分。
9.4.?Innodb_max_purge_lag–这个是用来限制事务每次所能更新或者删除最大的行数。将会延迟insert/update操作，所以清除线程会被保持。
9.5.?为什么我们不用多个清除线程呢？
10.?并发控制设置
10.1.?设置可以帮助InnoDB适应于控制大量的并发事务。
10.2.?Innodb_thread_concurrency–InnoDB内核中同时可以允许最大的在线程数量（0表示没有限制），2*（CPU核数+磁盘数量）在理论上是一个合理的值，在实际应用中设置的更小一点可能会让性能更好一点。
10.3.?Innodb_commit_concurrency–允许同一时间内事务提交的最大线程数。
10.4.?Innodb_concurrency_tickets–在不得不退出内核空间和等待之前能运行线程的数量。
10.5.?Innodb_thread_sleep_delay
10.6.?Innodb_sync_spin_loops
11.?获得高性能的不安全方式
11.1.?Innodb有一些检查和方法是数据不被最小化丢失和错误。
11.2.?Innodb_doublewrite–这个值是用来保护部分页的修改，只是禁止假如OS保证它不会发生。
11.3.?Innodb_checksums–在页中的数据校验码，帮助发现文件系统错误，内存损坏和其它问题。
11.3.1.?导致一部分大工作负载的机器会过载。
11.3.2.?当性能是第一的情况下可以禁止这个参数。
12.?Innodb?SHOW?STATUS部分
12.1.?Mysql5.0有一些性能计数信息通过show?status能够显示出来。
12.1.1.?它们都是全局的，虽然大部分其它技术信息都是针对每个线程的。
12.1.2.?它们大部分都是从show?innodb?status中获取的。
12.2.?下面将显示其中的一些指标。
12.3.?Innodb_buffer_pool_pages_misc–其他缓存页需要的在innodb?buffer中所使用到的页。
12.4.?Innodb_buffer_pool_read_ahead_rnd–innodb处理的随机预读的数量。
12.5.?Innodb_buffer_pool_read_request,?innodb_buffer_pool_reads?这2个值是用来计算缓存读的命中率的。
13.?Show?innodb?status
13.1.?这个是innodb故障处理的工具。当发生问题时就输入“show?innodb?status”
13.2.?这时候就会显示一些比show?status更详细的信息。
13.3.?一些关于现在正在运行中的事务的信息（列入它们的锁等等）
13.4.?最新的一个死锁和外键的信息等等
13.5.?一些关于latches,spinlocks(自旋锁)，操作系统等待信息
13.6.?更详细的参考http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/
14.?Show?mutex(互斥量)?status
14.1.?一个用来显示在你的工作负载下哪些热门的互斥量的工具
14.2.?显示了哪些是真正发生的互斥量，自旋锁的细节，以及操作系统等待。
14.3.?Timed_mutexes?–?跟踪操作系统等待了多久
硬件和操作系统的选择
15.?硬件和操作系统选择的检查列表
15.1.?使用什么CPU，以及多少个？
15.2.?使用多大的内存？
15.3.?如何建立IO子系统（如RAID）？
15.4.?使用哪个文件系统是最好的选择？
16.?选择CPU
16.1.?不同的CPU/架构对于innodb的扩展性能是不同的。
16.2.?老的“netburst”基于intel的xeon的扩展能力是比较弱的。
16.3.?新的酷睿基于xeon和?AMD的opterons具有更好的可扩张性
16.4.?X86_64是非常必须的。
16.5.?使用多核处理器会让Innodb工作的更好
16.6.?每个系统拥有8核是一个比较合理的限制。
16.6.1.?必须根据实际的工作负载来进行调配
16.6.2.?Innodb必须要根据未来的预期负载进行
16.7.?外部扩展，使用多台性能?较低的终端服务器。
16.8.?32位的CPU马上就要被淘汰了，所以请不要再使用32位的操作系统。
17.?使用多大的内存
17.1.?内存经常是对于很好的应用程序调优的性能瓶颈。
17.2.?Innodb可以很有效的使用大量的内存。
17.3.?工作设定必须合理设置内存
17.3.1.?因为数据页是最常被访问
17.3.2.?不要通过行进行计数：100byte的行大概是1亿行，随机100万行的工作设定能够产生大部分的数据页。
17.4.?是总数据库大小的5%能够导致50%空间占用。
17.5.?确定使用64位的平台，操作系统和mysql版本。
18.?如何建立IO子系统
18.1.?Innodb可以很好的加载大部分的磁盘驱动。每个节点有6-8个是一个看上去最优的配置。
18.2.?直接能够访问到的存储通常工作的最好
18.3.?SAN–会增加恢复时间，而且价格昂贵
18.4.?NAS–可以避免很多数据错误的风险
18.5.?ISCSI–在大部分业务中都是非常适合的，也会增加恢复时间
18.6.?RAID–电池备份cache是非常重要的。一定要确认启动了在写入cache的时候有电池备份。
18.7.?硬盘自身的缓存一般都是需要关闭。或者确认使用fsync()写入数据到磁盘或者当操作系统崩溃的时候能够产生数据腐坏。
19.?本地存储的配置
19.1.?日志最好放到单独的raid1中。这个是非常有帮助的，在很多情况比放在跟数据一起更好。
19.2.?二进制日志最好放到单独的卷中–能够很好的帮助备份和恢复。
19.3.?RAID10对于表空间非常好。比预期下降的性能更多。
19.4.?RAID5对于特定的工作负载时好的。仅仅需要确认是否需要降低性能。
19.5.?大的RAID条带大小（128K+）在理论是最好的，但是很多RAID控制器不能非常好的去控制。
19.6.?软RAID也是不错的，特别是RAID1。
20.?操作的选择也有会有问题？
20.1.?需要考虑性能，工具的有效性，社区等等。
20.2.?Windows–试用于开发环境，很低的扩展性的WEB/企业项目上。
20.3.?Solaris–提供了一些非常好的工具，也能对Mysql提供很好的支持，但是缺乏社区支援。
20.4.?FreeBSD–历史上Mysql有很多问题在这个平台上，现在是好多了，但是只有很少的工具可用，很少在生产环境中使用。
20.5.?Linux–在生产环境中和开发环境中最常使用的平台。有一些像LVM,JFS这样的工具可以使用。
21.?文件系统的选择
21.1.?主要是linux环境中有很多文件系统可以选择
21.2.?EXT3–很多Linux发行版的默认文件系统，工作的非常好对于终端安装。
21.3.?ReiserFS–很多Linux支持这个迁移。通常没有打的问题在标准的Mysql工作负载下。
21.4.?XFS–被用在有RAID驱动的情况下，能够提供不错的性能提升。
21.5.?JFS–很少被使用
21.6.?Raw分区（原始分区）针对innodb表空间—很少使用
21.7.?通常非常高的性能提升预期都是通过更改文件文件系统来获得。
最近InnoDB的性能开发
22.?InnoDB可伸缩性的补丁
22.1.?减少了buffer?pool也中竞争。在5.0中直接可用，在4.1中需要自己移植。
22.2.?在MySQL5.1提升了sync_array的实现。
22.3.?基于工作负载，硬件环境，并发上的性能提升跟原来有所不同。
22.4.?从很少的百分比到很多次的进行排序。
22.5.?性能还是会在很大数量的并发线程的情况下有所下降。
22.6.?未来可扩展实现补丁的原型都是来源于社区的。
23.?其它改进
23.1.?在Mysql5.1中行级别复制减轻了间隙锁的问题。
23.2.?在没有auto_increment”talbe?locks”能够继续工作。
23.3.?数据库页中支持ZIP压缩
23.4.?更快的索引建立
23.4.1.?不再需要全表重建
23.4.2.?可以根据物理分片的索引进行排序。