在构建高并发业务系统时，数据库的事务一致性与并发处理能力直接影响整体性能。MySQL作为经典关系型数据库，与分布式数据库TiDB在设计理念上有明显不同，这也导致它们在事务和并发表现上各有优劣。
事务模型的基本差异
MySQL的InnoDB引擎使用基于锁的并发控制加上多版本并发控制（MVCC）来实现事务隔离。它主要运行在单机或主从架构中，事务边界清晰但受单节点资源限制。
TiDB兼容MySQL协议，但底层是分布式存储（TiKV）。它采用 Percolator 模型的事务，通过全局时间戳（TSO）分配事务版本，在分布式环境下保证ACID特性。
MySQL事务示例
-- 开启事务 START TRANSACTION; -- 扣减库存 UPDATE product SET stock = stock - 1 WHERE id = 1001; -- 创建订单 INSERT INTO orders(user_id, product_id) VALUES (10, 1001); COMMIT;
TiDB中类似的事务写法
BEGIN; UPDATE product SET stock = stock - 1 WHERE id = 1001; INSERT INTO orders(user_id, product_id) VALUES (10, 1001); COMMIT;
从语法看两者基本一致，但TiDB在提交时会向PD获取时间戳并做两阶段提交，网络开销比单机MySQL更大。
并发性能对比
在并发读写方面，两者的瓶颈位置不同。下面用表格列出典型差异：
| 维度 | MySQL | TiDB |
|---|---|---|
| 扩展方式 | 垂直扩容或分库分表 | 水平扩容节点 |
| 写并发瓶颈 | 单机磁盘与CPU | Region调度与网络延迟 |
| 读并发 | 依赖缓存与从库 | 多副本并行读取 |
| 锁冲突 | 行锁竞争激烈时下降快 | 分布式的乐观锁减少热点 |
编程时需要注意的点
- MySQL高并发写建议控制事务粒度，避免长事务占用锁。
- TiDB应尽量避免频繁更新同一行，防止Region热点。
- 使用连接池时，MySQL可设较小超时；TiDB因分布式提交慢，可适当放宽。
用代码观察事务耗时
下面这段Java代码演示如何简单记录MySQL与TiDB的事务执行时间：
import java.sql.*;
public class TxTest {
public static void main(String[] args) throws Exception {
// 连接串可换成TiDB或MySQL
String url = "jdbc:mysql://127.0.0.1:4000/test";
Connection conn = DriverManager.getConnection(url, "root", "");
long start = System.currentTimeMillis();
conn.setAutoCommit(false);
PreparedStatement ps = conn.prepareStatement("UPDATE account SET balance=balance-? WHERE id=?");
ps.setInt(1, 10);
ps.setInt(2, 1);
ps.executeUpdate();
conn.commit();
System.out.println("cost=" + (System.currentTimeMillis() - start));
conn.close();
}
}
注意上述代码中如果换成TiDB地址，提交阶段会因获取TSO而增加少许延迟，但在多节点并发下总体吞吐往往更高。
如何选择
如果你的业务数据量在单机可承受范围，且事务简单、延迟敏感，MySQL更合适。当数据规模持续增大、并发请求跨越单节点能力时，TiDB的分布式事务与弹性扩展能力会更突出。理解它们在事务与并发上的本质区别，才能做出稳妥的技术决策。