理解mysqldump原理 --single-transaction --lock-all-tables --master-data

在mysqldump过程中，之前其实一直不是很理解为什么加了–single-transaction就能保证innodb的数据是完全一致的，而myisam引擎无法保证，必须加–lock-all-tables，前段时间抽空详细地查看了整个mysqldump过程。

理解–single-transaction：

打开general_log，准备一个数据量较小的db，开启备份，添加–single-transaction和–master-data=2参数，查看general_log，信息如下，每一步添加了我的理解

myisam引擎为什么无法保证在–single-transaction下得到一致性的备份？
因为它压根就不支持事务，自然就无法实现上述的过程，虽然添加了–single-transaction参数的myisam表处理过程和上面的完全一致，但是因为不支持事务，在整个dump过程中无法保证可重复读，无法得到一致性的备份。而innodb在备份过程中，虽然其他线程也在写数据，但是dump出来的数据能保证是备份开始时那个binlog pos的数据。

myisam引擎要保证得到一致性的数据的话，他是如何实现的呢？
它是通过添加–lock-all-tables，这样在flush tables with read lock后，直到整个dump过程结束，断开线程后才会unlock tables释放锁(没必要主动发unlock tables指令)，整个dump过程其他线程不可写，从而保证数据的一致性

如果我一定要在mysiam引擎中也添加–single-transaction参数，再用这个备份去创建从库或恢复到指定时间点，会有什么样的影响？
我个人的理解是如果整个dump过程中只有简单的insert操作，是没有关系的，期间肯定会有很多的主键重复错误，直接跳过或忽略就好了。如果是update操作，那就要出问题了，分几种情况考虑

1） 如果是基于时间点的恢复，假设整个dump过程有update a set id=5 where id=4之类的操作，相当于重复执行两次该操作，应该问题不大
2） 如果是创建从库，遇到上面的sql从库会报错，找不到该记录，这时跳过就好

3）不管是恢复还是创建从库，如果dump过程中有update a set id=id+5 之类的操作，那就有问题，重复执行两次，数据全变了。

理解–lock-all-tables

打开general_log，准备一个数据量较小的db，开启备份，添加–lock-all-tables(其实也是默认设置)和–master-data=2参数，查看general_log，信息如下，理解–lock-all-tables怎么保证数据一致性