理解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位置等信息