理解mysql_事务原理及常见优化思路

WAL机制， 先采用日志的方式将操作记录下来，然后刷新磁盘。
InnoDB遵循WAL协议，在日志持久化到磁盘之后，才会将日志对应的脏页刷 回磁盘；

InnoDB内存中，DML操作顺序如下：
– 写Undo(获取ROLLBACK_PTR系统列)
– 修改Page
– 写Redo的顺序

不同的Update语句，写的日志量有较大差异(三种Update Case)；
– In Place Update日志量最小，操作最简单；
– 不修改主键列，日志量其次；
– 修改主键列，日志量最大，操作最复杂；


日志文件：
redo：保证事务的持久性
顺序写，基本上不用读操作，只有在异常down机后才会读进行数据恢复操作。
何时写： 事务提交时
当log buffer中有一半的内存空间已经被使用时
log checkpoint时
实例shutdown时
binlog切换时
undo：
保证事务的原子性
事务回滚及mvcc控制
随机读写。

每执行一次事务，都需要做一次fsync操作，因此磁盘的性能影响fsync的性能, fsync性能也就影响到数据库的性能。 数据库可以通过参数来控制，提交事务时不写日志，而是由异步操作来刷日志，但是异常时会丢一个周期内的事务数据。

innodb_flush_log_at_trx_commit参数设置 0\1\2
默认 1
1 ： 每commit一次调用一次fsync写日志，写数据文件
0： 异步控制，mysql线程每隔1秒异步执行fsync, db crash 会有1秒的数据丢失
2： 异步控制，写入操作系统缓存，不进行fsync，由操作系统进行调度fsync，操作系统crash会有数据丢失。

二进制日志与重做日志的区别：
1、二进制日志所有存储引擎都有的，而重做日志只有innodb才有
2、二进制日志是逻辑日志，里面记录了sql语句，而重做日志是物理日志，记录的是每个页的修改page位置等信息