Mysql innodb存储引擎的性能优化二

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. 可以根据物理分片的索引进行排序。