总的来说，Ext3的cache算法性能还是非常不错的，不愧是linux上面备受推崇的文件系统。InnoDB虽然提供了高可用性，但是插入性能方面的表现并不如MyISAM稳定。
INNODB HOT BACKUP是一个商用的可执行文件。不过可以申请30天试用下。
相比MYSQL自身的MYSQLDUMP 导入导出工具来说有以下优点：
1.物理备份。
2.还原速度快。
而MYSQLDUMP在并发小的时候还可以用下。缺点如下：
1.逻辑备份。
2.还原速度慢。
而LVM则可以喝INNODB HOT BACKUP有一拼了，不过有个缺点，就是要建立逻辑卷，而且备份的时候必须得建立跟源数据所在卷一样的临时卷。其他的优点和INNODB HOT BACKUP一样。
不过INNODB HOT BACKUP的缺点也是有的，就是只备份INNODB的表空间以及生成新的REDO 日志。
对于表结构的备份可以直接用MYSQLDUMP来个快速逻辑备份， 或者可以用 INNODB 官方给的开源PERL 脚本来配合备份表结构。
今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug：在 5.1 版本中，Innodb 存储引擎如果使用autocommit=0的情况下，单条SQL在执行过程中如果异常中断的话，事务完整性可能无法保证，不论是STATEMENT还是MIXED的binlog_format，都存在相同的问题，可以重现，屡试不爽。
我们开发自己的存储引擎页面缓存替换策略的过程中主要是参考了InnoDB与LRU-K算法。InnoDB缓存替换策略使用分代与LRU相结合的方式。分为old和young两个分代，系统维护old分代占总buffer大小的3/8左右。当一个页面第一次被访问时，是加入到old分代的lru头。并不是每次访问一个页面时就将这个页提到lru的头部，而是在这个页面在LRU中的位置调整后，是否有很多页面已经被替换出去，若有，则将这个页面移到LRU头。系统在每个页记录调整该页在lru中位置当前系统总共替换了多少个数据页，比较页中记录的这个计数与系统全局页替换计数，就可以发现上次调整这个页在lru链表中位置后，系统中又有多少个页被替换，若比较多，则再次调整该页在lru中的位置。由于第一次访问的页被加入到old分代中，因此一次表扫描不会导致young分代中的页被替换出去。
