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的桥梁，用于实例恢复时判断事务是否成功提交的依据。
