1、Xid:

Xid是用来联系bin log和redo log的。

存在于binlog和redolog之中。

在宕机后进行恢复时，判断事务是否已经提交成功，还是说需要回滚。

比如redo log里面有一个事务是prepare状态(第1阶段提交)，那就可以用Xid去binlog里面查询该事务有没有提交：

• binlog有提交：则认为即使redolog中的事务是prepare也认为提交成功了（即：只要完整写入了binlog，即使没有第2阶段提交redolog了，也认为没有那个必要了）；
• 若binlog中没有提交：则回滚该事务。

Xid是由server层维护的：Xid首先是存在于binlog的，即Xid的根在binlog。

show binary log;
show binlog events in 'mysql-bin.000002';

分析输出，可以看到Xid的身影：

•     由dml组成的事务才会有，标志着事务的结束(COMMIT)
•     Xid在ddl事务中没有，可将Query值视为Xid

另外，Gtid在dml ddl事务中都有，标志着事务的开始(BEGIN GTID ...)。

InnoDB存储引擎为了进一步支持实例恢复而发明的redolog，借用了Xid。

InnoDB存储引擎层内部借用server层的 Xid，就是为了能够在 InnoDB 事务和 server 之间做关联。

2、trx_id：

trx_id一大作用是用来联系MVCC版本链和.dbf文件的。(trx_id是事务对象的主键，唯一标识一个事务对象)

存在于.dbf文件()中，以及MVCC版本链中。（.dbf文件中每行数据都有个对应的trx_id，表示这行数据是由哪个trx_id事务造成的）

在MVCC版本链快照读取时，会判断这行数据能否读到。

比如trx_id会随着事务执行增删改时，写入.dbf文件(表示这行数据是由哪个trx_id事务造成)；这些trx_id也会随着事务的开始写入MVCC版本链中。用于判断能否读到这个版本的数据。

trx_id是由存储引擎层维护的。

3、两者比较：

Xid 和 InnoDB 的 trx_id 是两个容易混淆的概念。Xid 是由 server 层维护的。InnoDB 内部使用 Xid，就是为了能够在 InnoDB 事务和 server 之间做关联。但是，InnoDB 自己的 trx_id，是另外维护的。

trx_id，innodb存储引擎层，由InnoDB维护，是事务对象的主键，唯一标识一个事务对象。同时dbf每行数据都有个对应的trx_id，表示这行数据是由哪个trx_id事务造成的。作用：MVCC版本链读取时，会判断这行数据能否读到。 Xid，server层，但MySQL使用Xid，作为引擎层redolog和server层binlog的桥梁，用于实例恢复时判断事务是否成功提交的依据。