mysql innodb的学习（一）_MySQL

bitsCN.com

mysql innodb的学习（一）

 

mysql下最常用的两个存储引擎一个是Myisam，另一个是innodb，关于这两个引擎的区别和比较，网上有好多，这里就不再说明了，这里主要讲一下innodb的各个参数的作用和对性能的影响。其中对性能影响最明显的两个参数innodbbufferpoolsize和innodblogfilesize。

innodbbufferpool_size 这个参数可以说是对innodb的性能有着决定性的作用，缓冲区的大小决定了innodb性能的好坏。缓冲区不仅缓存innodb的索引，还存储了数据、自适应哈希索引（adaptive hash index）、插入缓存、锁、以及其他的一些内部结构。这个值的大小怎么设置呢，设置多大才合适呢，mysql的配置文件中给出的建议是设置为服务器内存的50%-80%，但是在32位的机器中，mysql的手册中有一个警告：    

 

在32位GNU/Linux x86上,你必须要小心不要设置过高的内存用量。glibc可能允许进程堆积在线程堆栈上发展，它会造成你的服务器崩溃。如果下列表达式的值接近或者超过2GB，系统会面临危机：innodbbufferpool_size + keybuffersize（myisam使用的缓冲区）+ maxconnections*(sortbuffersize+readbuffersize+binlogcachesize)+ maxconnections*2MB

 

innodb使用这个缓冲区来延缓write，所以可以将多个write合并，然后顺序的写到disk中，这样可以将原来的随机写改进到顺序写，提高数据写的效率。 innodb对写操作的执行过程为先将写操作的改动写到buffer pool中，然后记录操作日志到log file（日志文件的配置参数为innodblogfile_size）中，然后就返回结果到客户端，这样就提高了innodb的响应速度（不需要等写到磁盘后再返回，在内存中的操作会比在磁盘上的操作快），而在buffer pool改动过的记录就是“脏数据(脏页)dirty page”。 那接下来问题就来了：

 

innodb是怎么把buffer pool中的“脏页”写到磁盘的呢？

innodb的缓冲区中能保存多少dirty page呢？

对于第一个问题，innodb使用一个后台的线程来刷新（flush）数据到磁盘（将多个写操作合并执行，可以将随机写改为顺序写来提高效率） 对于第二个问题，innodb中使用参数innodbmaxdirtypagespct来控制dirty page在buffer pool中的最大比例，当达到这个值时，innodb就会使用flush thread来将数据写到磁盘（如何写将在后续中讨论），当没有达到这个值时，innodb的flush线程会在buffer pool中没有足够的空间来写新数据时执行flush的操作，这个行为称为“懒执行（lazy）”,就是innodb可以延迟flush操作。 延迟执行不代表就不执行了，因为如果在服务器压力比较大的情况下（有大量的并发写），buffer pool中就会有很多的dirty page，那么就会很容易达到innodbmaxdirtypagespct，那么flush thread就会要尽量快将buffer pool中dirty page刷新到磁盘中，以降低脏页在缓冲区中的比例。

 

虽然buffer pool对innodb的性能有很大影响，但是也不是越大越好，越大的缓冲区对mysql服务的关闭和启动就要执行越长的时间。比如缓冲区中有很多的“脏页”，innodb要花相对长的时间来将脏页刷新到磁盘中，只有等所有的脏页都刷新后，mysql才会关闭。当然也可以使用快速关闭，但是启动的时候，mysql要花相对长的时间来恢复，所以对于关闭和启动这整个流程来说，大的缓冲区还是对这整个流程的时间来说要相对长。 我们可以在mysql运行过程中动态的调整innodbmaxdirtypagespct值，动态的设置相对小一些，可以是flush线程尽快的将脏页刷新到磁盘，后再执行关闭的操作，这样可以从某一方面来说缩短关闭的时间。我们可以通过SHOW INNODB STATUS命令来查看当前脏页的数据innodbbufferpoolpagesdirty。

 

如果我们有一个大的缓冲区和一个慢的磁盘，那么服务器重启时就会要花一个相对长的时间来预热，这个对于mysql的整体性能也会有一定的影响。

 

bitsCN.com