MySQL 技术内幕：InnoDB存储引擎——读书笔记（八）

hfutwhy

    事务特性：ACID（Atomicity、Consistency、Isolation和Durability），原子性、一致性和持久性通过数据库的redo和undo来完成，而隔离性是通过锁来实现的。

    预写日志方式(Write-Ahead Logging，WAL)：先写日志，后刷数据。InnoDB通过redo日志和日志缓冲(InnoDB Log Buffer)来实现。事务开始时，记录LSN；事务执行时，往Log Buffer中插入事务日志；提交时，将日志缓冲刷新至磁盘（默认实现方式，即innodb_flush_log_at_trx_commit=1）。

    通过SHOW ENGINE INNODB STATUS\G可以查看当前磁盘和日志的“差距”：Log sequence number(当前的LSN)，Log flush up to(刷新至redo log文件的LSN)，Last checkpoint at(刷新至磁盘的LSN)。

    事务更改数据时，会产生redo，同时会产生一定量的undo（undo存放共享表空间的undo segment中）。对于undo页的回收则是在master thread中进行的。

事务控制语句

• START TRANSACTION / BEGIN：存储过程中只能通过START TRANSACTION开启事务。
• COMMIT / ROLLBACK
• SAVEPOINT identifier /RELEASE SAVEPOINT identifier：创建/删除保存点
• ROLLBACK TO [SAVEPOINT] identifier：与SAVEPOINT一起使用，回滚到标记点。
• SET TRANSACTION：设置事务的隔离级别。（SERIALIABLE的事务隔离级别主要用于InnoDB存储引擎的分布式事务。）

1. completion_type=0时，COMMIT=COMMIT WORK
2. completion_type=1时，COMMIT WORK=COMMIT AND CHAIN，表示提交后立刻开启一个相同隔离级别的事务。
3. completion_type=2时，COMMIT WORK=COMMIT AND RELEASE，表示提交后自动断开与服务器的连接。

    在一个事务中，多个SQL语句，如果其中一条语句失败，并不会导致该事务的结束，并不会导致先前已经执行的语句的自动回滚。同样，ROLLBACK TO SAVEPOINT也并没有结束该事务，依然需要COMMIT或ROLLBACK显示提交。

    对于DDL、DCL以及管理语句(如ANALYZE TABLE、CACHE INDEX、CHECK TABLE、LOAD INDEX INTO CACHE、OPTIMIZE TABLE及REPAIR TABLE)，都是隐式提交的。TRUNCATE TABLE语句是DDL语句。

    QPS（Question Per Second）

    TPS（Transaction Per Second）：( com_commit + com_rollback ) / time。（计算的为显示提交的事务）

    InnoDB支持XA事务，通过XA事务可以来支持分布式事务的实现。分布事务指的是允许多个独立的事务资源(transactional resources)参与一个全局的事务中。（此时InnoDB的隔离级别必须为SERIALIABLE）

    分布式事务由一个或多个资源管理器（Resource Managers）、一个事务管理器（Transaction Manager）以及一个应用程序（Application Program）。

• 资源管理器：提供访问事务资源的方法。通常一个DB就是一个资源管理器。
• 事务管理器：协调参与全局事务中的各个事务，需要和参与全局事务中的所有资源管理器进行通信。
• 应用程序：定义事务的边界，指定全局事务中的操作。

 

不好的事务习惯

• 在循环中提交：会造成磁盘的IO操作增加，效率降低。
• 使用自动提交
• 使用自动回滚

    对于事务的BEGIN/START TRANSACTION、COMMIT和ROLLBACK操作，应该交给程序端来完成，从而避免意想不到的错误。

注：如涉及版权或者其他问题，请联系本人。