InnoDB之Dirty Page、Redo log
分类: MySQL基础知识 | 发布: OurMySQL | 来源:Taobao DBA Team
标签: Dirty Page, InnoDB, Redo log
在InnoDB中,buffer pool里面的dirty page一方面可以加快数据处理速度,同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生,以及InnoDB如何利用redo log如何消除dirty page产生的数据不一致。
|
本站Feed
在InnoDB中,buffer pool里面的dirty page一方面可以加快数据处理速度,同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生,以及InnoDB如何利用redo log如何消除dirty page产生的数据不一致。
innodb,innodb_buffer_pool_size,innodb_flush_log_at_trx_commit,Innodb_additional_mem_pool_size,Innodb_lock_wait_timeout,innodb_support_xa,Innodb_log_buffer_size,Innodb_log_file_size
以测试的表结构而言,4000万的数据量以内,insert的性能是缓步下降的,并未出现性能拐点。然而过小的buffer设置会引起频繁的交换,出现类似性能拐点的现象。结合之前的select性能测试,可以认为Innodb基本上不存在所谓的性能拐点。只要正确估计数据量,合理设置内存,就可以避免出现性能瓶颈。对于分布式MySQL系统来说,单表的最大数据量取决于整个数据库的总数据量、相应的表结构以及服务器的硬件设置。
在3000万数据的范围内,未出现所谓的性能拐点。初步猜想,前人的实验结果出现性能拐点,是因为内存耗尽,MySQL需要从磁盘上读取数据引起的。而这种性能拐点与MySQL本身的实现机制无关。
总的来说,Ext3的cache算法性能还是非常不错的,不愧是linux上面备受推崇的文件系统。InnoDB虽然提供了高可用性,但是插入性能方面的表现并不如MyISAM稳定。