作者： Jayjlchen
差异概览
特征 | TiDB | MySQL （官方版本） |
数据库类型 | 分布式 | 单机或多实例 |
事务处理 | 支持分布式事务 | 单机事务处理 |
扩展性 | 原生支持分布式扩容 | 利用中间件，分库分表并人为维护 |
性能 | 性能与数据库大小无关 | 单表数据超过 2000 万可能性能下降 |
复杂 SQL 能力 | 强 | 弱 |
HTAP 能力 | 支持 | 不支持 |
高可用 | 原生支持 | 需人工部署并维护 |
存储引擎 | rocksdb | innodb |
数据结构 | LSM Tree | B+ Tree |
版本差异
（截至 2024 年 7 月31日）
特征 | TiDB | MySQL （官方版本） |
最新稳定版本 | 7.1.5、7.5.2、8.1.0 | 8.0.39、8.4.2 |
小版本发版周期 | 如 7.5.1、7.5.2大约 1-3 月 | 如 8.0.36、8.0.37大约 1-3 月 |
大版本发版周期（LTS） | 如 6.5、7.1、7.5大约每 6 个月发布一次主要版本 | 如 8.0、8.4数年发布一次主要版本 |
分支 | 社区版、企业版 | 社区版、企业版、Percona、MariaDB |
近期 EOL 版本 | TiDB v4.0 系列已于 2024-04-02 EOL | MySQL 5.7 系列已于 2023-10-31 EOL |
LSM Tree VS B+ Tree
读放大
MySQL 的读放大
如果一次主键查询，索引层高在 3 层就是 3 次 IO，表超过 2000 万行，有可能会达到 4 层，那么就是 4 次 IO，IO 操作相当于增加 33%。
TiDB 的读放大
先去 LSM Tree 的 MemTable 查找，最新的数据会写在这里，如果命中则返回。
如果没找到，继续到 Immutable Memory Table 查找，找到则返回。
如果再找不到，则搜查 SST 文件的缓存 Block Cache，找到则返回。
如果还没找到，则会开始读取磁盘 SST 文件，会依次搜索 L0 至 L6 各个层级的内容。每一层的文件都会配备一个布隆过滤器。
- 过滤器对一个 Key 如果判断不存在，那么它一定不存在这个 SST 文件内，此时可以跳过这个文件；
- 如果判断在文件内则它可能在可能不在，无法判断准确，此时会直接去查文件内容，由于 SST 文件严格有序，所以在文件内是效率较高的二分查找。
直到找到数据后，通过 gRPC 调用返回查询结果。
写放大
MySQL 的写放大
比如 会写入到索引合适的位置，因此是随机 IO。插入操作实际上可能引起整个叶节点块的重写（参考索引分裂的原理），即使只是添加了一个新的记录。
TiDB 的写放大
写入是顺序 IO，写入效率很高，但也存在写放大。
TiDB 的写放大主要体现在数据从 L0 逐步向下合并到 L6 的过程中：
- 从 L0 到 L1 的合并：当 L0 的数据积累到一定程度，系统会自动触发 L0 与 L1 的合并操作。在此过程中，L0 的数据会被重新排序并压缩成 L1 中的 SSTable。这个过程会导致写放大，因为数据不仅需要被重新写入，还可能涉及到删除标记的处理。
- 从 L1 到 L6 的后续合并：类似地，当 L1 的数据积累到足够多时，它会与 L2 合并；依此类推，直到 L6。在这些合并过程中，数据会被不断压缩和优化，但每次合并都会产生写放大。
空间放大
经验值，3T 的 CSV 文件导入 TiDB 后会占用 4.5 至 6T 的存储空间（包括三副本），就算宽裕估算比值也是 1 : 2 的关系。相比于 MySQL 三副本使用的数据体积，这个压缩率已经相当可观。
总结：
LSM-tree 的写性能比 B+tree 好，而读性能不如 B+tree。TiKV 使用 LSM-tree 而不是 B-tree 作为其底层存储引擎的主要目的是因为使用缓存技术来提升读性能比提升写性能容易得多。
同样是 3 副本对比，如 一套 3 副本 TiDB 集群，对比 MySQL 一主两从架构，TiDB 集群更省空间。
架构差异
与传统非分布式数据库架构相比， TiDB 具有以下特点：
- 两者都支持 ACID、事务强一致性
- 分布式架构，组件解耦，拥有良好的扩展性，支持弹性的扩缩容
- 默认支持高可用，在少数副本失效的情况下，数据库能够自动进行故障转移，对业务透明
- 采用水平扩展，在大数据量、高吞吐的业务场景中具有先天优势
- 强项不在轻量的简单 SQL 的响应速度，而在大量高并发 SQL 的吞吐
对标的 mysql 架构（水平扩展，分库分表）
高可用架构差异
MySQL
- 一主一从
- 一主多从
- 一主多从——延迟复制
- 一主多从——不参与切换
- 一主多从——基于权重切换
- MHA
- MGR
TiDB
MySQL 的困境
●单点：无法容忍单点故障
●异步复制：无法保证一致性
●同步复制：难以保证一致性 / 难以故障转移
TiDB 基于 raft 的原生高可用
TiDB 其他常用架构
单区域双 AZ 方案（dr auto sync）
适合企业有双机房条件，两个机房相距 50 km 以内，机房间网络连接延迟小于 1.5 ms，带宽大于 10 Gbps。
- sync：同步复制模式，此时从 AZ （DR） 至少有一个副本与主 AZ （PRIMARY） 进行同步，Raft 算法保证每条日志按 Label 同步复制到 DR。
- async：异步复制模式，此时不保证 DR 与 PRIMARY 完全同步，Raft 算法使用经典的 majority 方式复制日志。
- sync-recover：恢复同步，此时不保证 DR 与 PRIMARY 完全同步，Raft 逐步切换成 Label 复制，切换成功后汇报给 PD。
单区域三 AZ 方案
除了常规部署在一个机房的架构，选择最多的架构是跨机房部署，ping 延迟要尽量低。
优点：
- 所有数据的副本分布在三个 AZ，具备高可用和容灾能力
- 任何一个 AZ 失效后，不会产生任何数据丢失 （RPO = 0）
- 任何一个 AZ 失效后，其他两个 AZ 会自动发起 leader election，并在一定时间内（通常 20s 以内）自动恢复服务
缺点：
性能受网络延迟影响。具体影响如下：
- 对于写入的场景，所有写入的数据需要同步复制到至少两个 AZ，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要两倍 AZ 间的延迟。
- 对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个 AZ，也会受网络延迟影响。
- TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个 AZ 时，TiDB 上运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。
优化后的架构
优点：
- 集群 TSO 获取能力以及读取性能有所提升。
缺点：
- 写入场景仍受 AZ 网络延迟影响，这是因为遵循 Raft 多数派协议，所有写入的数据需要同步复制到至少两个 AZ
- TiDB Server 是 AZ 级别单点
- 业务流量纯走单 AZ，性能受限于单 AZ 网络带宽压力
- TSO 获取能力以及读取性能受限于业务流量 AZ 集群 PD、TiKV 组件是否正常，否则仍受跨 AZ 网络交互影响
