作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/2345a664

最近几次遇到有同学问到 TiDB 和 MySQL 的性能对比咋样的问题，为了避免更多的人也会有类似疑问，本篇幅通过架构分析与基准测试两个角度，希望能够帮助大家打消对于此问题的疑虑。

两者在架构本质上完全不同

先谈一下 TiDB 产生的背景吧~ 时间回到 2015 年以前，三位豌豆荚的开发人员 (刘奇、黄东旭、崔秋) 因遭遇项目中单机缓存不足的问题一举开发了 Codis 轰动了整个技术圈。此后，他们又构想出要实现一个可以解决单机 MySQL 容量和性能瓶颈的数据库，这款数据库不仅能像 MySQL 一样去使用而且理论上可以进行任意的横向扩展，它就是后来的 TiDB。

TiDB 的整个架构实现并非基于 MySQL 代码来二次开发，底层不是多个 MySQL 组成的分库分表，而是借鉴了当时 Google 的 Spanner 思想而自研的一款原生分布式数据库。TiDB 的存储层不是 InnoDB 引擎，而是一个分布式可扩展的存储引擎 TiKV，这个存储引擎使用了 Raft 一致性协议实现了数据的多副本冗余，又使用了 MVCC 多版本并发控制解决了读写并发冲突的问题，还基于了 Google 的 Percolator 模型保证了分布式事务的一致性。为了能够方便原有 MySQL 的无缝迁移，使用 GO 语言完全重写了 MySQL 的 SQL 引擎层，保证了对 MySQL 协议和语法极高的兼容性。

以上为 TiDB 最初的设计思想，可以看到，TiDB 的产生并不是为了替换 MySQL，而是为了解决 MySQL 集中式瓶颈和无法有效扩展的问题。MySQL 是集中式数据库，通过主从复制来实现高可用保证；TiDB 是分布式数据库，数据库内部天生支持组件的高可用和数据的高可用。

关于 TiDB 和 MySQL 的性能对比这个问题，笔者个人的观点首先是两者根本就不是同一个架构的产品，没有必要进行对比。用 Oracle、PostgreSQL 去和 MySQL 对比倒还合理，因为他们均属于集中式架构；用 CRDB、YugabyteDB 去和 TiDB 对比才算合理，因为他们均属于原生分布式架构。 TiDB 和 MySQL 天生就不是相同的架构设计，TiDB 也不是为了取代 MySQL 而设计的产品。对于一些可能需要使用 TiDB 替换 MySQL 来满足信创替换要求的，我个人的建议是以满足业务需求为考量，不要盲目的去对比基准测试的性能。

为满足好奇心还是做了一个基准测试

虽然但是，为了满足同学们的好奇心，笔者还是从个人的角度去对比了一下 TiDB 和 MySQL 的基准性能。为体现对比的公平性，我们使用 sysbench 对比同样三节点的 TiDB 和 MySQL，其中 TiDB 采用三副本的混合部署模式、MySQL 采用一主两从半同步的部署方式，两套数据库均未做过任何优化。以下是一些对比结果展示，供读者参考。

• oltp_write_only

• oltp_insert

• oltp_read_only

• oltp_read_write

• oltp_point_select

• oltp_update_index

• oltp_update_non_index

基准测试对比的简单结论

通过以上的对比测试可以看到，在相同环境、相同表结构的前提下，

• MySQL 在低并发、基础数据量较小时性能可能优于 TiDB

• MySQL 性能随着并发增加性能会达到瓶颈，之后并发越高性能逐渐下降

• 当表基础数据量越大时，MySQL 性能有明显下降，而 TiDB 的性能仍然保持基本的准线性增长

• TiDB 中性能随着并发增加基本呈线性提升，当节点资源不够时，还可以通过动态扩容来提升性能

• 基础数据量越大，TiDB 比 MySQL 优势越明显，基础数据量为 2 亿时，TiDB 具有明显的优势

结语

架构的区别说清楚了，基准测试咱也做了，相信读者也应该有比较清晰的了解了。简单总结一下：MySQL 是单机库，适用于数据量小并发低的场景；TiDB 是分布式库，适用于数据量大、并发高且有高可用要求的场景。数据量越大，并发越高，TiDB 的线性扩展能力体现的就会越明显，反之它的优势则不明显。选择 MySQL or 选择 TiDB，还是先评估你的业务场景吧~