在微服务与数据量持续增长的环境下，事务是否能在多节点间保持一致，直接影响系统的可靠性。MySQL与TiDB都宣称支持事务，但底层机制差别明显，下面从几个关键维度做具体对比。
一、架构层面的根本差异
MySQL是典型单机关系型数据库，即使使用主从或组复制，单实例事务仍在本地完成。跨分片场景通常依赖中间件，例如用 XA 协议做弱协调，但运维复杂且易挂起。
TiDB采用计算存储分离架构，TiDB节点无状态，真正的事务协调由 Placement Driver 与 TiKV 多副本引擎完成，原生支持跨节点提交。
二、事务模型与隔离级别
MySQL InnoDB提供读已提交、可重复读（默认）和串行化；分布式下中间件往往只能保证最终一致。
TiDB使用Percolator模型，默认提供快照隔离（SI），等价于MySQL可重复读，且通过 MVCC 避免脏读与不可重复读。
简单对比表
| 维度 | MySQL | TiDB |
|---|---|---|
| 事务范围 | 单节点为主 | 原生跨节点 |
| 提交协议 | 本地提交/XA | 两阶段提交 |
| 默认隔离 | 可重复读 | 快照隔离 |
三、代码示例：两阶段提交感知
在TiDB中，应用层无需感知分布，直接写SQL即可；MySQL若用XA需显式控制。下面给出TiDB普通事务写法：
-- TiDB 原生分布式事务，自动跨节点 START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE id = 1; UPDATE account SET balance = balance + 100 WHERE id = 2; COMMIT;
MySQL使用XA做跨库事务时，代码明显更重：
XA START 'x1'; UPDATE db1.account SET balance = balance - 100 WHERE id = 1; XA END 'x1'; XA PREPARE 'x1'; XA COMMIT 'x1';
四、性能与运维成本
MySQL单机事务延迟低，但分库分表后跨节点事务吞吐量下降明显。TiDB在中等冲突下表现平稳，热点key可能带来写争用，需要合理设计主键。
- MySQL：易上手，生态成熟，分布式事务需额外组件
- TiDB：弹性扩容好，事务对业务透明，但集群运维门槛略高
五、如何选择
若业务规模可控、强依赖单机性能，MySQL仍是稳妥选择；当数据突破单机容量且要求跨节点强一致时，TiDB的分布式事务能力更具优势。
结论：两者并非替代关系，而是按事务边界与数据规模做取舍。