最近几次遇到有同学问到 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，还是先评估你的业务场景吧~