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