分布式事务允许多个独立的事务资源参与到一个全局的事务中，全局事务要求所有参与的事务要么都提交，要么都不提交。XA是一套分布式事务规范，本文所说的XA事务是指基于XA协议的分布式事务。XA协议下，分布式事务通常由一个全局事务管理器，一个或多个局部资源管理器，以及一个应用程序组成： 应用程序（AP）：定义事务边界，并指定构成事务的操作 资源管理器（RM）：提供对共享资源的访问 事务管理器（TM）：为事务分配唯一标识符，监视其进度，并负责事务的提交，回滚和故障恢复 MySQL的XA事务中，MySQL是资源管理器，事务管理器是连接MySQL的客户端。XA的协议主要描述了事务管理器与资源管理器之间的接口
MVCC (Multiversion Concurrency Control)，多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。 MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的。本文讲解InnoDB中MVCC的实现机制（MySQL其它的存储引擎并不支持它）。
change buffer（在 MySQL 5.6 之前叫 insert buffer，简称 ibuf ）是 InnoDB 5.5 引入的一种优化策略，若二级索引页不在 buffer pool 中，则将针对二级索引页的操作暂时缓存起来，等到该页从磁盘读到 buffer pool 中时再批量的（batch）apply 这些操作，从而达到减少磁盘 I/O 的目的。具体一点就是： 事务 1 执行写操作（e.g update），但针对的二级索引页 P1 并不在 buffer pool 中 于是 client 1 将这个操作缓存到 change buffer 里，即添加一个 entry（ibuf insert） 事务 2 需要读操作，将 P1 读到 buffer pool 中 将 change buffer 里相关的缓存的操作全部合并（merge）至 P1（ibuf merge） 将 P1 返回给用户线程
大家好，我是田哥 今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种： redo 日志 undo 日志 binlog 日志 比如更新语句的流程会涉及到 undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）这三种日志： undo log（回滚日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。 redo log（重做日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复； binlog （归档日志） ：是 Server 层生成的日志，主要用于数据备份和主从复制；
电商业务场景，随着平台订单规模的日益增长，订单现有的存储已经没办法支撑后面业务的发展。在得物五彩石项目的时候就对订单进行了分库分表的拆分，为了解决分库分表后卖家维度的查询问题，单独创建了一个卖家维度的订单库。 目前订单分为买家和卖家两个库，卖家库的数据是通过监听买家库binlog异构出来的一个库。现在订单主要有两张表，分别是订单的主表和子表。 在异构的逻辑中，我们会对这两张表的binlog消息进行处理，异构成我们的卖家订单表。在监听到插入的消息时，只会处理子表的插入消息，其余需要补充的主订单表数据直接查询主表。
