TiDB vs MySQL：从架构原理到平滑迁移的工程实践指南

在 2015 年前后，团队的分库分表方案一度让我非常头疼。单个 MySQL 的单机容量走到瓶颈后，技术选型团队尝试过 MyCAT、ShardingSphere-Proxyd 之类的中间件，又把主从复制拆成多套，结果业务层动不动就报“跨库查询不支持”“分布式事务状态不一致”，排查问题要从多个 MySQL 实例里拉日志。后来朋友推荐我去看 TiDB，说它能保留 MySQL 的连接协议和 SQL 习惯，同时解决“扩容不用改代码”的问题。

这篇不打算给你背书式地把产品文档念一遍。我以比较偏工程落地的视角，把 TiDB 本身的定位、最核心的架构分层、以及大多数人会纠结的“tiDB 和 MySQL 的区别”聊透，最后给出一套从 MySQL 迁移到 TiDB 时比较稳妥的路线和踩坑经验。如果你正在评估 TiDB，或者被单机 MySQL 压得有点喘不过气，这篇会对你比较有帮助。

1. 为什么 TiDB 会出现在这个时间点：从 MySQL 容量焦虑说起

1.1 单机数据库的扩容短板，不是加内存就能填补的

MySQL 本身是一个足够成熟的关系型数据库，但在互联网业务量增长到一定阶段，所有人都会撞上同样的墙：单实例的 CPU、内存、磁盘 IO 即使不停升级硬件，性能曲线也会越来越难看。磁盘扩容容易，内存扩容后 InnoDB 的缓冲池、连接数、锁冲突却不会同比例变好。

大多数人遇到这个瓶颈后的第一反应是分库分表。把用户表按 user_id 哈希成 64 张表，或者把订单表按月分表，听起来没有技术难度，实际上后续灾难无穷。

分库分表的痛点很典型：

• SQL 路由规则写死之后，业务代码里到处都是“先路由到哪个库再执行”的逻辑，后期改分片键等于重写。
• 跨分片的 JOIN、子查询、聚合函数全部变成高级需求，要么回内存里 Merge，要么直接在应用层做二次加工。
• 唯一键、分布式 ID、事务变成最麻烦的部分。两个分片之间要同时写数据时，常见做法是本地消息表和接口补偿，不仅技术上费劲，数据不一致时的定位成本更高。
• 运维层还得自己做一套数据迁移、扩缩容脚本，每加一个分片就要重新平衡数据。

分库分表本质上是“把一个大数据库拆成很多个小 MySQL”，它在数据层加了一层中间件逻辑。这套东西不是不能用，但维护成本不低。TiDB 能出来，就是因为它在保证分布式扩展能力的同时，不让业务感知分片的存在。

1.2 TiDB 的定位：兼容 MySQL 生态的分布式数据库

TiDB 是开源的分布式关系型数据库，核心目标是把 MySQL 当作“前台兼容层”，后台换成一套能水平扩展的分布式存储引擎。业务方不需要改变连接 MySQL 的方式，不需要自己再维护一套 Sharding 中间件，只把连接地址换到 TiDB 集群，就能获得接近无限的水平扩展能力。

这个方向很聪明的一点在于，它继承了 MySQL 现有的驱动和生态。你在 Java 里用的 JDBC、在 Python 里用的 PyMySQL 或 mysql-connector-python、在运维里用的 mysqldump 等工具都可以直接连上去操作。开发团队不用额外学习一套新的开发模型。你该写 SQL 还是写 SQL，该做 ORM 映射还做 ORM 映射，TiDB 会像 MySQL 一样回报结果。

但 TiDB 并不仅仅是“开源版的 MySQL 集群”。它解决了 MySQL 生态里比较难处理的几个点：

• 数据可以自动分片，且分片对业务透明；
• 支持跨节点的分布式事务，保持真正的 ACID；
• 具备多副本同步复制机制，故障时自动切换，不需要人工干预。
• 存储层和计算层可以独立扩展，业务量大时加节点即可。

因此，TiDB 的定位准确来说是：一款具备 MySQL 协议兼容能力的分布式关系型数据库。对于中小项目来说，MySQL 也许没有太大问题；但如果业务清晰可见地会持续增长，TiDB 的架构方式能为未来留下更大的空间。

2. TiDB 架构中最核心的三块组件，以及为什么这样拆分

很多人第一次打开 TiDB 官方文档会被 TiDB、TiKV、PD、TiFlash 各种组件绕晕。不要紧，我先用一张比较直观的分层关系帮你捋清它们。

TiDB 从大的逻辑上看是两层结构：

• 计算层（TiDB Server）：负责接收 SQL、解析 SQL、生成执行计划、再把任务发往后端存储层，最后汇总结果集。
• 存储层（TiKV 和 TiFlash）：负责真正存数据，并以多副本的方式保证数据可靠性。其中 TiKV 存行式数据，主要承担在线交易读写；TiFlash 存列式数据，负责分析型查询。

在这两层之上还有一个 PD（Placement Driver），按官方说法是“调度模块”。它像总指挥一样管理整个集群的数据分布、副本平衡和事务时间戳分配。

如果用一个面向真实场景的样例来说明，你可能会更容易理解。

2.1 一次 SQL 查询在 TiDB 中是怎么被处理的

假设业务里有一张商家订单表 t_order，数据量变得很大。你用 MySQL 客户端输入一条：

sql复制SELECT buyer_id, SUM(amount)
FROM t_order
WHERE status = 'paid'
GROUP BY buyer_id;

这条 SQL 到 TiDB 里，执行过程如下：

1. 请求先到 TiDB Server。它是对客户端开放的接入层，监听 4000 端口，兼容 MySQL 协议。
2. TiDB Server 做词法语法解析，生成逻辑计划，转化成物理执行计划。
3. 执行计划发现这张表的数据在存储层分成了很多块，于是把任务拆成多个小任务，下发到对应的 TiKV 节点。
4. 各个 TiKV 节点并行扫描自己管理的那部分数据，做聚集计算后返回中间结果。
5. TiDB Server 汇总所有中间结果，最终把完整结果返回给客户端。

这条链路的关键点是：在 MySQL 中，“SQL 层”和“存储层”是紧耦合在一个进程里的，而 TiDB 把它们拆成了独立的分布式模块。因为存储层能分布在不同机器上，所以查询天然能并行，扩容时只要加机器就行，不需要像 MySQL 那样在大实例里加锁加缓冲区。

2.2 TiKV：行式存储、多副本与 Raft 一致性

TiKV 是 TiDB 的行式存储层，内部数据默认按主键范围切成一个个数据块，官方称这些数据块为“Region”。每个 Region 都会维护多个副本，副本之间通过 Raft 共识算法保持同步。

Raft 算法你可能听过，但简单说，它的意义是：当一个 Region 的数据要被修改时，Leader 副本负责接收写入请求，并把改动同步到多数派 Follower 副本，只有多数派写入成功，事务才算提交。这样出现少数机器宕机时，数据不会丢。

相比 MySQL 传统的主从复制，TiDB 的多副本同步有明显差异。MySQL 的主从复制通常以 binlog 为中心，主库异步或者半同步地发给从库；如果主库瞬间宕机，从库可能没收到最后几条 binlog，切换时容易出现数据不一致，需要额外做数据校验。而 TiDB 的 Raft 同步机制会保证超过半数节点都持有最新数据后才返回成功，少数节点故障不影响整个集群。

TiDB 内部的 Region 可以自动拆分和合并。当单 Region 数据量达到阈值后，PD 会把它拆成两个；当某个 TiKV 节点负载相对较高时，PD 还会把部分 Region 调度到其他负载低的节点上。这个过程对应用完全透明，不需要人工介入去调整分片。

2.3 PD 和全局时间戳：分布式事务为什么能保持一致性

分布式数据库和单机数据库最大的不同在于：单机数据库可以用一把全局的锁或者一个序号来保证事务的先后绝对一致，但分布式环境下，多台机器之间存在网路延迟，如果没有全局统一的节奏，合并事务时就会乱套。

PD 在其中扮演的角色很关键。它会根据 Raft 算法选出一个唯一的时间戳分配器，后续所有事务在开始时都会向 PD 申请一个全局递增的时间戳 TSO。事务的先后顺序就按 TSO 排序，这样即使两个事务分别落在不同的 TiKV 节点上，也总能确定谁先谁后。

我用个生活类比解释：一个多人团队协作修改同一份在线文档时，肯定会因为网络延迟出现先后冲突。如果没有全局唯一时间轴，两个人可能同时编辑同一个段落，最后结果取决于哪台服务器先保存。而 TSO 相当于给每个编辑操作盖章一个全局递增的序号，大家都按这个序号合并，任何两台机器都不会产生歧义。TiDB 的分布式事务模型借鉴了 Google Percolator 的思路，先保证全局快照一致，再通过两阶段提交完成真正的事务提交。

很多从 MySQL 转过来的开发最担心一件事：“分布式环境是不是真的能做到 ACID？” 实际生产环境里，TiDB 对单行、跨行、跨表事务都支持，只要应用层遵循常规事务写法就行。TiDB 同时支持乐观事务和悲观事务；默认实现更接近悲观锁，可以减少大量事务冲突时的重试。

2.4 TiFlash：面向分析查询的列式引擎

TiFlash 并不是 TiDB 的可选摆设，它是 HTAP（混合事务和分析处理）能力的关键组件。生产系统的常见需求是：白天业务并发高，但业务想当天实时看报表，汇总数据量大，这时如果所有分析查询都打在行式存储上，OLTP 的写入性能会被拖得很难看。

TiFlash 以列式存储收留分析型负载。TiDB 会把写入 TiKV 的数据以异步复制的方式同步到 TiFlash，构建列式副本。业务查询时，可以按表指定让优化器选择读取 TiFlash，例如：

sql复制SELECT /*+ read_from_storage(tiflash[t_order]) */ buyer_id, COUNT(*)
FROM t_order
GROUP BY buyer_id;

这个 hint 会让查询直接读取 t_order 在 TiFlash 中的列式副本，而不是走到 TiKV 的行式副本。优点很明显：列式存储在聚合扫描场景下会大幅减少无用列的读取，分析查询不会影响在线写放大的主路径。

不过需要提醒大家，TiFlash 不是全自动透明。我们需要在 DDL 阶段为关键表创建列式副本，也需要通过 hint 或者优化器开关控制查询到底走 TiKV 还是 TiFlash。这部分配置和 MySQL 没有对应概念，导入 TiDB 的团队一定会遇到。

3. TiDB 和 MySQL 的区别，我从工程视角梳理出的关键差异

用户最关心的动态“tidb和mysql的区别”并没有一个简单的结论。下面我按实践中所影响的技术点拆开来讲，表格放在前面方便你有个整体把握。

单看表还不够，因为每个差异背后都会带来实际开发习惯的改变。

3.1 SQL 兼容方面：很像 MySQL，但不是完全克隆

TiDB 官方长期宣称“MySQL 兼容”，对于大多数业务来说，你原来写的 SELECT、INSERT、UPDATE、DELETE 及常见 DDL，基本不需要改就能直接运行。但如果你把它当成人肉 MySQL，完全按 MySQL 的冷门语法去写，将不可避免踩坑。

我遇到的几个实际差异：

外键约束。 MySQL 在 InnoDB 表结构里比较容易使用外键，由于外键在写入时的每次 check 会大幅限制分布式写入性能，TiDB 历史上长期只是尽量不支持强外键约束，最近几个版本才逐步加入外键语法，但主要仍是为了兼容以前 SQL 生成的 DDL 导入，实际使用中建议应用层去维护外键关系。如果在代码里大量依赖数据库的外键级联操作，迁移时一定会有明显的不适应感。

AUTO_INCREMENT 的行为。 MySQL 单表自增主键在单机内是严格递增和唯一的。TiDB 也支持自增主键，但因为是分布式，数据会分散在多个 TiKV 节点，自增计数无法做到像 MySQL 那样集中顺序分配。所以，TiDB 会提供“全局唯一但非连续”的自增值，如果你盲目地拿自增主键去判断业务上的先后顺序，会有细微差异。

更值得注意的一点是，在有主键的 TiDB 表中，如果主键是整数且是单调递增的，那么新插入的数据主键会连续落到同一个数据块 Region 中，形成热点写入，这会让单台 TiKV 处于高负载，导致扩容带来的红利被抵消。TiDB 为这个问题提供的官方解法是 AUTO_RANDOM 主键，写入时会自动分配随机全局 ID，让新数据的写入分散到不同 Region。更详细的表字段设计会在后面的迁移建议里讲到。

视图、触发器、存储过程。 TiDB 对视图的支持相对不错，但对存储过程和触发器的兼容程度不如 MySQL。MySQL 用户大量使用存储过程时，迁移前需要把这些逻辑梳理一遍，把复杂存储过程改成应用层的事务逻辑。

字符集和排序规则。 TiDB 的默认字符集在较新版本中通常是 utf8mb4，但 MySQL 8.0 的排序规则与旧版本差异本来就很大，直接导入数据时，个别字符串比较行为需要先在测试环境里验证。

系统表和变量。 很多运维监控脚本会查 MySQL 的 information_schema 或 performance_schema 做巡检，在 TiDB 中这些系统库虽然存在但结构并不完全一致。运维上的 MySQL 状态变量，例如 SHOW GLOBAL STATUS LIKE 'Threads_connected' 有一部分无法直接反映集群真实状态。因此，建议及早引入 TiDB 官方的监控体系，不要依赖以前的 MySQL 巡检脚本。

3.2 事务隔离级别与锁机制的世界观差异

MySQL InnoDB 默认的事务隔离级别是 REPEATABLE READ（可重复读），并且通过间隙锁和临键锁解决幻读。TiDB 的默认隔离级别同样是可重复读，但表现方式不一样，TiDB 的快照隔离机制可以保证同一事务在不同节点读取到一致的统一快照。

不过，TiDB 对每条写操作的成本判断会更重。TiDB 引入的乐观事务与悲观事务的取舍值得一提。在老版本里，TiDB 乐观事务冲突较多时会导致大量重试，而现代版本默认走悲观事务路径，整体感受更接近 MySQL。如果真的遇到热点行高并发更新，即使 TiDB 能水平扩节点，但同一个热点行的锁竞争仍会限制吞吐，这一点和 MySQL 非常相似——分片可以解决数据量，解决不了单一热点行的物理竞争。

3.3 存储引擎层差异：从 B+ 树到分布式 KV + Raft

从数据库原理角度看，MySQL InnoDB 用 B+ 树作为聚簇索引，所有数据按主键组织在 B+ 树中，每行数据都挂在叶子节点。TiDB 则把一张表的数据转换编码为 key-value 形式落的 TiKV 中，存储引擎使用基于 LSM-Tree 的引擎。LSM-Tree 在写入大规模随机数据时通常有更好的顺序 IO 表现，这也是 TiDB 依赖批量数据写入能力更强的原因之一。

但 LSM-Tree 的问题在于后台 Compaction 会消耗很多 IO 资源，所以 TiDB 的读写放大比 MySQL 复杂。不是 TiDB 在性能上一定能全面甩开 MySQL，如果业务场景是单机容量完全够用、并发不高，那 TiDB 不会有明显优势，反而会在部署、运维上更重。只有在真正要水平扩展、数据规模达到 TB 级别、并发和容量都出现瓶颈时，TiDB 的架构优势才会爆发出来。

4. 从 MySQL 切换到 TiDB：一个可落地的迁移方案

很多团队在 POC 阶段就止步了，因为 TiDB 和 MySQL 表面上太像，一测又觉得各种细节不一样。下面我以一套实际迁移流程为基础，列出比较稳妥的做法。

4.1 迁移前的评估清单，按优先级排一遍

建议不要一上来就部署集群。先拉一条 SQL 审计日志，把应用里所有可能访问到大表的 SQL 采集下来，在测试环境跑一遍，发现不兼容点时即使止损。我建议重点检查以下项：

• 使用了 MySQL 存储过程/触发器/外键的模块；
• 自增主键在业务代码里是否承担了“生成顺序”的语义；
• 依赖 MySQL 特殊函数的 SQL，例如 JSON_TABLE、GROUP_CONCAT 排序行为、某些日期函数的边界；
• 分页查询中的大偏移量场景，这类查询在分布式环境下需要扫描的数据量更大，容易出现性能回落；
• 是否有连接 MySQL 的旧客户端版本低于 5.7 时期的情况。虽然 TiDB 兼容多数 MySQL 协议，但极老的客户端可能存在协议兼容瑕疵。

评估完成前，不要做数据导入。确保 SQL 兼容性测试通过再考虑数据迁移，是能省下大量重复工作的关键。

4.2 数据迁移的完整步骤与工具选型

TiDB 官方提供了一整套迁移工具，通常组合使用：

• Dumpling：负责从 MySQL 全量导出逻辑数据。早期常用 Mydumper 作为类工具，TiDB 的这个 Dumpling 在控制并行度、并发一致性快照方面做得更顺手，比如：

  bash复制dumpling -u root -p 123456 -h 127.0.0.1 -P 3306 \
    -t 8 -o /data/backup -F 256MiB -B mydb
  

  导出时要注意 MySQL 的 GTID 或 binlog 位点，确保后续增量同步能接上。

• TiDB Lightning：是 TiDB 官方强推的高性能导入工具，支持从 Dumpling 导出的 SQL/CSV 文件直接导入 TiDB。它会把文件切块并跨 TiKV 并行写入，速度远快于慢慢执行 SQL 文件。

• DM（Data Migration）：负责增量同步，可持续从 MySQL 同步 binlog 到 TiDB，适合停机窗口很小、需要双跑迁移的场景。

在实际操作中，我最常用的是“全量 + 增量”模式：先用 Dumpling 和 Lightning 把数据库全量同步到 TiDB，然后通过 DM 追增量 binlog。切换时选择一个低峰期，确认 TiDB 数据追平 MySQL，然后把应用连接串从 MySQL 3306 改到 TiDB 4000 端口。这样由 MySQL 到 TiDB 的切换整体风险比较低。

注意，导入阶段不要把外键约束原样带过去，否则 Lightning 的并行导入速度会被牢牢拖死。先把表结构里的外键去掉，业务层在应用层自行保证引用关系，导入成功后如有必要再评估是否启用外键。这一步和我前面讲的 TiDB 外键策略一致。

4.3 表结构改造建议之一：主键设计的再审视

迁移中我强烈建议你重新评估每个大表的主键类型。MySQL 时代很多 DBA 都推荐“隐式自增主键”，因为 InnoDB 按照主键组织数据时，自增主键很容易保证顺序写。但到了 TiDB 这里，自增主键的分布会导致热点问题，规模越大越明显。

如果某个表长期执行高频 insert，又没有业务上需要排序的可见主键，最优解是改成使用 AUTO_RANDOM：

sql复制CREATE TABLE t_order (
  id BIGINT AUTO_RANDOM PRIMARY KEY,
  buyer_id BIGINT NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  status VARCHAR(20)
);

TiDB 会自行生成全局唯一的随机整型，让写入尽量分散到多个 Region 上。这样写事务不仅不会把单点顺序 ID 捅到一台 TiKV 里，而且可以天然利用 TiDB 的水平扩展能力。如果业务主键必须可见、必须顺序，那就只能结合采用缓存或发号器将 ID 打散。

4.4 上线后需要注意的运维差异

TiDB 集群上线后的运维工作比 MySQL 多一个维度。过去 MySQL 主要通过慢查询日志、主从延迟、InnoDB 状态来分析问题；TiDB 则建议直接上官方监控大屏，重点看以下几类指标：

• TiDB Server 的内存和 CPU，一般 SQL 解析与执行计划生成都在这一层汇聚；
• TiKV 的磁盘 IO、Raft store 延迟、CPU 使用率，它的延迟直接代表底层数据读写是否稳定；
• PD 的调度状态、leader 数量、心跳延迟，如果 PD 本身抖动，整个集群都会受影响。

你在生产上遇到 TiDB 查询变慢，不要只盯执行计划，要学会看某张表的热点分布。如果某个 Range 对应 Region 的读流量明显高于其他，原因多半是主键设计还不够分散，或者查询条件没有按主键访问。

5. TiDB 在哪些场景下不一定合适

并不是所有 MySQL 场景都适合升级到 TiDB。一个常见的错误是把 TiDB 当成性能加速器，而不是分布式扩容器。

如果你的业务数据总量在几 GB 到几百 GB 之间，单机 MySQL 通过索引优化、配置调优、读写分离就能满足需求，那引入 TiDB 可能弊大于利。TiDB 分布式架构的最小部署往往需要多个节点才能构成高可用集群，怎么也得 6 个以上节点才能有比较好的生产容错；相比一两台 MySQL 实例，资源开销明显更大。

另外，如果你的业务场景有极强的小事务低延迟诉求，例如一个事务只操作一行数据，且要求个位数毫秒延迟，和 MySQL 直连相比，TiDB 的网络开销和多节点 Raft 同步仍然会带来一定额外成本。TiDB 适合的是数据量已经让 MySQL 难以承受、需要扩容、并希望继续保持事务能力和 SQL 便利性的业务。

从项目初期的角度出发，我更推荐一个折中策略：小步沿用 MySQL 起步，观察数据库负载与代码迭代频率。当单机 MySQL 开始频繁抖动，分库分表改造又会拖垮产品迭代时，再上 TiDB 也不迟。因为 TiDB 的迁移链路已经比较成熟，不需要因为“赶技术热点”而提前引入复杂度。

6. 关于 TiDB 几个容易误读的点

我从实际项目里看到很多团队成员会对 TiDB 产生过高的预期，这里集中澄清几个容易误解的地方。

6.1 TiDB 并不慢，也不是“加了层皮”的 MySQL

有人做过简单测试，发现单节点 TiDB 跑某个查询比单机 MySQL 慢，就说它性能不行。这种对比意义有限。TiDB 的优势是测数据量增大、节点增多以后整体吞吐和稳定性仍能保持。拿单节点去和优化得非常成熟的 MySQL 单机比低延迟，本身就不公平。但如果网上看到“TiDB 真快”，也一样要冷静，需要考虑测试场景是否是分布式压力场景。

6.2 兼容 MySQL 不代表完全无痛

TiDB 从 5.0 到 8.x 的版本很多新特性在持续补齐 MySQL 兼容细节。可对依赖本地错误码、进程内线程变量、MySQL 比较隐晦写法的应用来说，迁移仍需要认真做回归。

举一个真实例子：团队成员曾在 TiDB 上执行某条 update 连接 MySQL 存在唯一约束组合键的表时连续报主键冲突，但查看后发现同一个主键的业务数据分布在 Region 边界，TiDB 对事务冲突重试的接口和 MySQL 的错误码有差异，应用里的重试逻辑必须额外补充幂等处理，否则会因为重复执行造成负数库存。

分布式数据库一定要强调“事务接口的重试幂等性”，这比单机 MySQL 更值得重视。

写到这里，我其实想强调的是：想做 TiDB，不要只盯着官网的“分布式”“强一致”“HTAP”等名词。它和你过去玩的 MySQL 确实很像，但存储引擎、调度逻辑、扩缩容机制都完全不同，只有当你理解了它和 MySQL 的边界，才知道在什么阶段、用什么姿势上它。多个项目的使用经验告诉我，迁移 TiDB 最忌讳的是直接拿着 MySQL 的旧表结构和 SQL 盲跑上去，前期愿意花时间的评估和测试，往往比后期想尽办法救火值钱得多。