flush tables with read lock的一个潜在问题

看了mysqlperformance的一篇关于flush tables with read lock的文章，里面提到了它可能引发一些问题。好了，现学现卖，分享给大家。

现在很多的mysql备份工具在实现原理上都利用到了flush tables with read lock。这是为备份myisam表而设计的。像xtrabackup备份innodb表时并不会锁表，因为它也会备份在备份过程中新发生的事务日志，而对于myisam表的备份则是通过发出命令flush tables with read lock，然后拷贝myisam的相关表文件。那么在实际备份过程中可能会出现什么问题呢？答案是：有可能导致备份的时间严重的增长。下面来说说为什么会这样。

flush tables with read lock，也就是将所有的脏页都要刷新到磁盘，然后对所有的表加上了读锁，于是这时候直接拷贝数据文件也就是安全的。但是如果你发出命令flush tables with read lock时，还有其他的操作，而起是很耗时的操作呢？先说写操作，这个FTWRL肯定是得等的，等写操作完成才能执行FTWRL，这个很好理解。那么对于其他的读操作呢？比如说在FLWRL发出之前有一个query：select count(*) from tb，那么FTWRL也得等待(show processlist可以看到 waiting for table flush)。你可能会说在mysql中读与读不是不会排斥的吗，为什么需要等待呢？因为FTWRL是要flush脏页的，只有这样才真的能保证数据一致性(比如说在xtrabackup备份myisam表的时候)，而在select count(*) from tb执行的时候，因为所有的操作都是在内存中操作，所以此时还不能完全flush，因此FTWRL就得等待。或许你还会有疑问，select的页不是脏页，为什么FTWRL还要等待呢？难道mysql不能做得更完善点吗？我觉得mysql还不是不会做的这么简单吧，等待的原因是因为这个表很大，无法一次性将所有的页都读到内存中来，而query具有原子性，总不可能执行一般被堵塞吧，所以说还是得乖乖的让它执行然，所以FTWRL就得等待了。

所以在利用xtrabackup、ibbackup这种备份工具的时候，也要考虑到这点，在另一篇文章里面提到了由于DDL语句对备份造成的影响。