从MySQL分库分表到TiDB：外贸系统数据架构弹性改造实践

外贸业务数据系统有一个很典型的尴尬期：订单量还在涨，数据库却先撑不住了；查询接口为了避开单表数据量，硬生生改成了按月份拆库；报表和在线事务争抢同一个实例的 CPU，一到月底结算，客服和财务同时来反馈系统变慢。如果你正在经历这个阶段，或者未来大概率会经历，那么这篇文章应该对你有用。

外贸赋能中心的数据架构迭代，本质上是一次从“分库分表 + 多套存储拼装”走向“分布式底座 + 弹性扩展”的过程。本文围绕这次实践中沉淀下来的几个关键判断展开：为什么要放弃继续在 MySQL 分库分表上加码，TiDB 在什么场景下值得引入，从旧库迁到 TiDB 有哪些看起来简单、实际很容易踩坑的环节，以及改造之后如何验证“弹性”是真的落地了，而不是换个数据库图个心理安慰。

读完你会理解，所谓数据弹性，不是简单地把数据量做大，而是当业务峰谷、数据增长、查询模式变化时，系统能通过水平扩展和资源隔离自动消化冲击，业务代码几乎不用跟着改。这篇文章会从痛点、选型、架构、迁移、改造、验证、排错和工程实践几个维度完整展开，建议收藏备用。

1. 这篇文章真正要解决的问题

先回答一个最直接的问题：什么样的数据团队应该读这篇文章？

• 正在使用 MySQL 分库分表，但已经感受到跨分片查询、聚合报表、分布式事务越来越难做的团队；
• 业务有明显峰谷特征，例如外贸、电商、金融结算，日常流量平稳但月末、大促、活动期会突然翻几倍；
• 系统里同时存在订单库、结算库、报表库、搜索索引，数据要在多个存储之间同步，链路长且经常对不上账；
• 技术负责人已经在评估 TiDB、OceanBase 等分布式数据库，但不确定迁移成本和工作量。

本文不会把 TiDB 吹成万能方案，也不会只复制官方文档里的架构图。我会把外贸赋能中心这类业务中台在数据架构迭代中真正遇到的问题、判断逻辑和实施路径讲清楚。尤其是“为什么 TiDB 能解决 MySQL 分库分表解决不了的问题”和“迁移过程中哪些环节最容易翻车”，这两点是读者最该带走的内容。

需要说明的是，外贸赋能中心可以理解为面向外贸业务线的中台型业务中心，核心流程覆盖订单、关务、物流、结算等环节。这类系统对数据架构的要求非常典型：既要在线事务的高并发和强一致，又要复杂查询和批量统计的高吞吐，同时还必须应对多币种、多语言、多时区带来的数据复杂性问题。

2. 外贸赋能中心的数据痛点：旧架构为什么撑不住

2.1 分库分表解决了一部分问题，也带来了新问题

很多外贸系统的早期架构都走过同一条路：业务量上来之后，先把单表拆成按月分表，再按商户或站点分库，最后引入 ShardingSphere 或 MyCat 这类中间件。

分库分表确实缓解了单库容量和写入瓶颈，但也埋下了几个长期隐患：

第一，跨分片 JOIN 基本不可用。订单主表按 order_id 分片，订单明细表也按 order_id 分片，单订单查询没问题。可一旦要按商品、按国家站点、按时间范围去查，“先把数据捞出来再在内存里拼”就成了常态，代码里全是循环查库和内存聚合。

第二，分布式事务成本高。订单创建、库存扣减、结算入账、关务状态回写，原本在一个数据库里可以用本地事务搞定，分库之后要么靠 MQ 做最终一致，要么引入 Seata 这类分布式事务框架。业务代码里开始出现大量补偿逻辑，排查数据不一致问题时要同时翻数据库、消息队列和定时任务。

第三，DDL 变更非常痛苦。分库分表之后，给一个大表加索引，要在凌晨业务低峰期对所有分片逐个执行。如果分片数量多，一个索引变更可能要跑一两个小时，期间还不敢随意发版。

这些问题不是分库分表本身的错，而是它在数据量达到一定规模后，把复杂度显式地暴露给了业务代码。

2.2 日常业务与月底结算的“峰谷冲突”

外贸业务有一个很明显的负载特征：日常订单量平稳，但每到月底，财务结算、对账、关务补录、汇率重估又同时启动。

白天是在线订单的读写高峰，晚上又是批量结算和报表加工的高峰。如果事务型数据库和分析型任务共用同一套 MySQL 实例，最直接的结果就是：白天报表任务还没跑完，晚上又和结算任务抢资源；结算任务一跑，线上订单查询的延迟立刻上升。

为了避免事务和分析互相干扰，很多系统会把分析任务引到从库或者数仓。但这带来的问题是：在线库里看不到全量历史数据，报表和业务查询要跨系统拉取，数据链路由 MySQL、Kafka、ES、Hive 多个组件拼成，任何一个环节延迟，都会导致当天报表数据不完整。

2.3 旧架构的隐性成本

这类架构的真正瓶颈不是单表数据量，而是“在线事务、复杂查询、批量计算”三种负载互相争抢资源。团队每天都在处理中间件同步延迟、索引失效、慢查询优化、数据不一致修复，真正投入业务功能开发的精力被大量稀释。

从材料看，更稳妥的判断是：如果业务还在快速增长，与其在分库分表之上不断打补丁，不如提前规划一个能同时承载事务与分析负载、可以水平扩展的底座。这也是 TiDB 进入选型视野的根本原因。

3. TiDB 的核心能力与适用边界：为什么它能成为弹性底座

3.1 TiDB 是什么

TiDB 是一款开源分布式关系型数据库，定位是 HTAP（Hybrid Transactional and Analytical Processing），意思是同一份数据既能支撑在线事务，又能支撑分析查询。

它最核心的架构特征可以简化为三层：

组件	角色	通俗解释
TiDB Server	SQL 层	负责接收 SQL、生成执行计划，对客户端透明，类似一个无状态的 MySQL 前端
PD（Placement Driver）	调度中心	负责集群元数据管理、Region 调度、负载均衡
TiKV	行存引擎	负责实际数据存储，数据按 Region 自动分片，支持分布式事务
TiFlash	列存引擎	以列存方式存储数据副本，专门加速分析型查询

对于业务开发来说，TiDB 最友好的地方是兼容 MySQL 协议。大多数情况下，你只需要把 JDBC 连接地址从 MySQL 改成 TiDB，原来用 MyBatis、JPA 写的 SQL 基本可以继续使用。这一点是它比很多新型数据库更容易落地的关键原因。

TiDB 的数据弹性来自它的自动分片和在线扩缩容机制。数据写入时自动按主键或索引拆分为若干 Region，Region 在 TiKV 节点之间自动均衡。当集群容量不足时，添加 TiKV 节点，系统会自动把一部分 Region 调度到新节点上，不需要应用层做任何分库分表操作。

3.2 适用于什么场景，不适用于什么场景

从实践角度看，TiDB 适合以下场景：

• 数据量达到千万级别以上，单机 MySQL 已经出现容量或性能瓶颈；
• 业务需要 MySQL 生态兼容性，不想因为换数据库重写全部 SQL；
• 在线事务与实时分析并存，希望减少 MySQL + ES + 数仓之间的数据同步链路；
• 业务有明显的流量波峰波谷，需要快速扩容、缩容。

不适合的场景也相当明确：

• 纯 KV 点查且对延迟极其敏感的场景，TiDB 不是最佳选择；
• 业务规模很小、单机 MySQL 完全能扛住，引入分布式数据库反而增加运维复杂度；
• 严重依赖存储过程、自定义函数、触发器这类数据库私有特性的系统，迁移成本可能远高于预期。

3.3 什么是“数据弹性”

数据弹性不是抽象概念。它至少包含四个可验证的能力：

1. 水平扩展能力：数据量和 QPS 增长时，通过加节点线性扩容；
2. 负载隔离能力：事务型查询和分析型查询能走不同引擎，互不干扰；
3. 在线变更能力：加索引、加列、调整表结构时不阻塞业务读写；
4. 故障自愈能力：单节点故障时，数据副本自动切换，业务无感。

外贸赋能中心的业务特征，恰好对这四项能力都有需求。月底结算高峰需要临时扩容，报表分析不能拖垮订单写入，关务表结构变更不能等待漫长的维护窗口。这正是 TiDB 被选为“数据弹性新底座”的原因。

4. 目标架构演进与选型要点

4.1 旧架构示意

改造前的外贸业务数据链路大致如下：

• 订单服务写入 MySQL 分库分表；
• 订单查询走 Elasticsearch，通过 Canal/Kafka 同步索引；
• 结算任务每天从 MySQL 抽取数据到 Hive/Spark 跑批；
• 月底报表依赖数仓加工后再回写到业务库。

这条链路的问题在于，同一个订单的数据在 MySQL、ES、Hive 里各存了一份，一致性靠同步任务保障。一旦同步延迟或者消息丢失，数据对不上，排查链路非常长。

4.2 新架构的目标形态

引入 TiDB 之后，理想的目标是让 TiDB 成为在线数据的统一底座，TiFlash 承担分析查询，业务分析型 SQL 直接跑在 TiDB 上，减少跨系统数据搬运。

新架构的核心要素：

能力	旧架构	新架构
在线事务存储	MySQL 分库分表	TiDB
复杂查询	ES + 应用层聚合	TiDB TiFlash / MPP
数据同步链路	MySQL → Canal → ES → Hive	TiDB → DM 同步到周边，链路明显缩短
弹性扩缩容	手动拆库拆表	在线添加 TiKV/TiFlash 节点
事务一致性	分布式事务框架	TiDB 原生分布式事务

需要强调的是，并不是所有数据都要立刻迁移进 TiDB。更稳妥的做法是先梳理数据热度：核心交易数据、结算数据、对账数据优先迁移；历史归档数据和超大日志数据仍然可以留在数仓或对象存储中。冷热分层不是退步，而是成本治理的必然选择。

4.3 选型要点

选型时不只看 TiDB 的性能指标，还要看三个工程因素：

第一是兼容性。业务代码里如果大量使用 MySQL 方言、存储过程、特定排序规则，迁移成本会显著上升。TiDB 对标准 SQL 和常用 MySQL 语法的兼容度较高，但遇到深度私有语法仍需改造。

第二是运维成熟度。TiDB 有较为完善的监控体系（Grafana + Prometheus）、备份恢复工具和在线扩缩容方案，这对外贸中台这类需要持续运营的业务非常重要。

第三是团队学习成本。DBA 需要理解 PD、Region、TiKV、TiFlash 等概念，业务开发则需要理解 TiDB 的慢查询分析方式和事务冲突处理方式。这部分成本容易被低估，但在实践中反而决定迭代成败。

5. 环境准备与 TiDB 集群部署

5.1 硬件与拓扑规划

TiDB 集群的最小拓扑通常由 TiDB Server、PD、TiKV 三部分组成。开发测试环境可以用少量节点混合部署，生产环境建议将 PD、TiDB Server、TiKV 分开部署，避免资源竞争。

TiKV 节点数量建议从 3 个起步，这是保证多副本和数据均衡的常见做法。TiFlash 则根据分析查询的并发量决定是否启用。

这里要特别提醒：不要照搬网上的部署文档而不看版本。TiDB 的版本更新较快，不同版本的部署参数、默认行为和推荐配置可能存在差异，版本请以 TiDB 官方文档当前发布为准。本文重点演示通用的部署思路。

5.2 使用 TiUP 部署集群

TiUP 是 TiDB 官方推荐的集群运维工具，可以用它来部署、升级、扩缩容集群。以下命令是一个典型流程，具体版本号请替换为实际使用的版本。

安装 TiUP：

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh source ~/.bashrc

准备拓扑文件。下面是一个简化的topology.yaml示例，仅用于说明结构，实际生产拓扑需要结合监控、目录隔离、标签配置等做调整。

global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" pd_servers: - host: 10.0.1.1 - host: 10.0.1.2 - host: 10.0.1.3 tidb_servers: - host: 10.0.1.11 - host: 10.0.1.12 tikv_servers: - host: 10.0.1.21 config: server.labels: zone: zone-a host: tikv1 - host: 10.0.1.22 config: server.labels: zone: zone-a host: tikv2 - host: 10.0.1.23 config: server.labels: zone: zone-b host: tikv3 tiflash_servers: - host: 10.0.1.31 - host: 10.0.1.32

部署并启动集群：

tiup cluster deploy <cluster-name> <version> ./topology.yaml --user tidb -p tiup cluster start <cluster-name>

命令中的<cluster-name>是自定义的集群名，<version>是 TiDB 的版本号，需要根据官方文档确认。

5.3 客户端连接验证

TiDB 默认兼容 MySQL 协议，端口通常是 4000。部署完成后，可以用 MySQL 客户端直接连接：

mysql -h 10.0.1.11 -P 4000 -u root -p

连接成功后执行SELECT version();，能看到 TiDB 的版本信息，说明集群的 SQL 层已经正常对外提供服务。

这一步是整个改造的“握手验证”。如果这里都通不过，后续所有业务迁移都无从谈起。

6. 数据迁移与业务改造路径

6.1 存量数据迁移工具链

从 MySQL 分库分表迁移到 TiDB，最常用的工具链组合是 Dumpling、TiDB Lightning 和 DM（Data Migration）。

• Dumpling 负责从 MySQL 导出数据，支持逻辑导出，适合在 MySQL 兼容场景下使用；
• TiDB Lightning 负责将数据高速导入 TiDB，适合初始化大量数据；
• DM 负责在线同步，支持 MySQL 到 TiDB 的全量 + 增量复制，适合业务不能长时间停写的情况。

迁移的基本流程是：先通过 Dumpling + Lightning 完成全量数据导入，再用 DM 追平增量，校验数据一致性后，将业务读写流量切到 TiDB。整个过程应当先在测试环境完整演练一遍，拿到准确的执行时间和风险点，再安排生产切换。

6.2 业务代码改造点

虽然 TiDB 兼容 MySQL 协议，但“兼容”不等于“零改造”。实际迁移中，以下几个点几乎总会遇到：

第一，分页查询。MySQL 的LIMIT offset, size在数据量大时性能很差，TiDB 同样存在这个问题。如果分库分表中间件之前帮你做了分页聚合，去掉中间件后要重新审视深分页 SQL。

第二，分布式事务。TiDB 支持跨行事务，但大事务会产生性能问题。一次事务写入的数据量过大、锁范围过宽，容易出现冲突和延迟上升。建议把批量操作拆成小批次，控制在合理范围内。

第三，自增主键热点。MySQL 分库分表下通常使用分布式 ID，迁移到 TiDB 后如果直接使用自增主键，写入会集中在单个 Region，形成热点。TiDB 的AUTO_RANDOM可以解决这个问题，但需要建表时提前设计。

6.3 权限与变更管理

迁移过程中，必须遵循最小权限原则。给业务账号配置所需的最小库表权限，避免使用 root 账号直接跑业务；所有表结构变更都走审批流程，先在测试环境验证，再在生产环境执行；涉及生产数据变更前必须确认备份可用。

这一步的价值在迁移出现问题时体现得最明显：有备份、有回滚方案、有灰度切换，才能把事故影响控制在最小范围。

7. 业务改造示例：订单、结算与 HTAP 落地

7.1 表结构设计示例

以一个典型的订单表为例。改造前 MySQL 分表后主键通常是业务生成的分布式 ID，改造到 TiDB 后，建议使用AUTO_RANDOM避免写入热点。

CREATE TABLE `order_info` ( `id` BIGINT NOT NULL AUTO_RANDOM, `order_no` VARCHAR(64) NOT NULL, `site_code` VARCHAR(16) NOT NULL COMMENT '站点编码', `currency_code` VARCHAR(8) NOT NULL COMMENT '币种', `order_amount` DECIMAL(18, 2) NOT NULL COMMENT '订单金额', `biz_date` DATE NOT NULL COMMENT '业务日期', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_order_no` (`order_no`), KEY `idx_site_biz` (`site_code`, `biz_date`) );

这个表结构的关键点不在于字段数量，而在于主键策略和索引设计。AUTO_RANDOM让 TiDB 在写入时自动生成分布均匀的主键值，避免自增主键造成的单 Region 热点。

7.2 Java 应用连接 TiDB

在 Spring Boot 项目中，使用 MySQL JDBC 驱动连接 TiDB 是常见做法。关键是连接串要配置合理。

文件路径：src/main/resources/application.yml

spring: datasource: url: jdbc:mysql://10.0.1.11:4000/trade?rewriteBatchedStatements=true&useServerPrepStmts=true username: trade_app password: "C0mplexPassw0rd" driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 20 minimum-idle: 5

连接串中的rewriteBatchedStatements=true对批量写入性能有明显提升，特别是订单明细这类批量插入场景。生产环境不建议把密码明文写死在配置文件里，应结合配置中心或环境变量管理。

7.3 HTAP 查询示例

外贸业务里一个典型需求是：按照站点和币种统计某个月的订单金额。过去这个查询要么在 MySQL 上跑很久，要么先同步到数仓再做 T+1 报表。在 TiDB + TiFlash 场景下，可以让这条分析型 SQL 直接在线执行。

SELECT o.site_code, o.currency_code, COUNT(*) AS order_cnt, SUM(o.order_amount) AS total_amount FROM order_info o JOIN currency_rate r ON o.currency_code = r.currency_code AND o.biz_date = r.rate_date WHERE o.biz_date >= '2024-01-01' AND o.biz_date < '2024-02-01' GROUP BY o.site_code, o.currency_code ORDER BY total_amount DESC;

如果查询优化器选择走 TiFlash，这条 SQL 可以在列存引擎上执行列式扫描和聚合，对在线 TiKV 的事务负载影响很小。

判断是否走了 TiFlash，可以先执行：

EXPLAIN ANALYZE SELECT /*+ READ_FROM_STORAGE(tiflash[o, r]) */ o.site_code, o.currency_code, COUNT(*), SUM(o.order_amount) FROM order_info o JOIN currency_rate r ON o.currency_code = r.currency_code AND o.biz_date = r.rate_date WHERE o.biz_date >= '2024-01-01' AND o.biz_date < '2024-02-01' GROUP BY o.site_code, o.currency_code;

TiDB 支持使用 Hint 引导优化器选择存储引擎，在验证阶段非常实用。正式环境不建议长期依赖 Hint，还是应该通过优化器统计信息和执行计划观察来调优。

7.4 在线 DDL 变更

迁移后的一个直接收益是表结构变更不再需要漫长的维护窗口。例如为订单表补充一个查询字段的索引，直接执行：

ALTER TABLE order_info ADD INDEX idx_created_at (created_at);

TiDB 的在线 DDL 机制不会阻塞业务读写，这让中台团队可以在工作日白天完成结构调整，不再为了一个索引等凌晨窗口。

8. 验证与压测：如何确认“弹性”真的落地

8.1 功能验证

迁移完成后，第一步不是压测，而是业务回归。需要覆盖订单创建、支付回调、物流状态更新、结算对账、报表统计等核心链路。

比较推荐的做法是准备一份线上脱敏数据，在测试环境做“影子验证”：新老系统并行运行一段时间，将相同请求同时打到 MySQL 和 TiDB，对比返回结果和耗时。这一步能发现绝大多数 SQL 兼容性问题。

8.2 压测方案

压测不建议上来就用极端参数把所有节点打满，而应该分阶段进行：

1. 先做单表基础读写验证，确认连接池、批量写入、事务提交正常；
2. 再做混合负载测试，模拟日常订单写入 + 分析型查询同时进行；
3. 最后做峰谷模拟，把月底结算的典型 SQL 组合在一起，观察延迟和资源占用。

常用工具包括 sysbench、tpcc 以及业务自定义压测脚本。观察指标应覆盖 QPS、TP99 延迟、CPU 使用率、TiKV Region 分布、是否存在热点等。

需要说明的是，拿不到真实业务数据时，任何压测数据都只能作为参考。更稳妥的方式是先小流量切换真实业务观察一段时间，再逐步放量。

8.3 弹性扩缩容验证

“弹性”验证需要刻意制造扩缩容场景：

• 在业务低峰期向集群添加至少一个 TiKV 节点，观察 Region 是否自动均衡，业务延迟是否出现抖动；
• 在业务高峰期执行一次临时扩容，确认写 QPS 提升后能快速消化负载；
• 确认缩容流程不会导致数据副本数低于安全阈值。

判断弹性是否达成的标准不是“扩容后峰值性能翻了几倍”，而是“扩容操作是否真的可以动态执行，业务是否无感”。

9. 常见问题与排查思路

问题现象	可能原因	排查方式	解决方案
写入集中在少量节点，出现明显热点	使用了自增主键，写入总落在单个 Region	查看 TiKV 热点图和写入流量分布	改用AUTO_RANDOM主键，或调整主键设计
分析型 SQL 很慢，但没有走 TiFlash	TiFlash 副本未同步完成，或优化器未选择列存	执行EXPLAIN ANALYZE查看执行计划	确认 TiFlash 副本状态，使用 Hint 临时引导
批量写入时事务冲突频繁	批量事务过大，锁范围过宽	查看 TiDB 慢日志和事务重试次数	拆分为小批量事务，开启相关重试参数
业务 SQL 在 TiDB 上报语法错误	MySQL 私有语法或函数不兼容	对比完整错误信息，定位具体 SQL	改写为标准 SQL，或使用 TiDB 兼容语法替代
迁移后对账数据不一致	增量同步期间漏数据或同步任务中断	使用数据校验工具比对新旧库	重新执行增量同步，并以源库为准修复
连接池报错 Too many connections	应用连接池配置过大，TiDB 连接数达到上限	查看 TiDB Server 的连接数和配置	调整max_connections，优化连接池参数

排查问题时最忌讳直接改 SQL 碰运气。第一步永远是看监控和执行计划。TiDB 自带的 Grafana 监控面板覆盖了 TiDB Server、PD、TiKV、TiFlash 各层的核心指标，慢查询日志和EXPLAIN ANALYZE能快速定位是扫描行数过多、索引失效，还是存储引擎选错。

10. 最佳实践与工程建议

10.1 分阶段迁移，先读后写

如果旧系统还在正常运行，不要追求一次性全量切换。建议把数据分为“只读分析型数据”和“在线交易型数据”两批。

第一批先迁移报表、对账、历史订单查询这类只读场景，让 TiDB 承担分析负载，验证 TiFlash 和复杂查询能力；第二批再迁移订单写入、结算事务等核心写路径。这样即使第一批出现问题，也不会影响线上交易。

这个顺序的好处是，风险按批次释放，团队有时间逐步掌握 TiDB 的运维节奏。

10.2 表设计要结合 TiDB 特性

迁移时不要直接复用 MySQL 表结构，至少检查以下几点：

• 主键是否会引起写入热点；
• 常用查询条件是否都有合适索引；
• 大字段是否应该拆到附属表；
• 数据保留策略是否明确，历史数据是否需要定期归档；
• 分区表是否有必要，TiDB 支持分区表但需要结合具体查询模式评估。

10.3 监控、备份、回滚三件套

生产环境使用 TiDB，至少要确认三件事：

1. 监控告警完整，TiKV 节点状态、Region 数、写入延迟、TiFlash 同步延迟都要有告警；
2. 备份任务定期执行，并且按周期做恢复演练，光有备份文件不能叫“可恢复”；
3. 切换方案里有回滚路径，迁移完成后保留旧 MySQL 链路一段时间，一般建议保留一个完整业务周期，例如一个月。

10.4 团队协作与变更评审

TiDB 上线之后，DBA 和业务开发的协作模式要跟着变。表结构变更、慢查询优化、集群扩容不再只是 DBA 的事，业务开发需要理解执行计划，DBA 需要理解业务查询模式。

建议建立“变更评审 + 灰度发布”机制：所有 DDL 和 SQL 上线前，先在测试环境观察执行计划，再由 DBA 评审，最后选择低峰期灰度执行。

11. 总结与后续学习方向

外贸赋能中心的数据架构迭代，本质上是把“分库分表中间件 + 多套存储拼装”的复杂度，转换为“分布式数据库底座 + 弹性扩展能力”。TiDB 在这个过程中的价值，不只是替换了一个数据库，而是把业务开发从分库分表、跨系统对账、凌晨 DDL 这些低效事务中解放出来，让团队能把精力放回业务本身。

这篇文章讲清楚了几个核心问题：为什么要从 MySQL 分库分表走向 TiDB，TiDB 的适用边界在哪里，迁移过程中有哪些容易踩坑的环节，以及如何验证弹性扩展能力是否真正落地。对于正准备做同类改造的团队，建议从只读分析场景开始试点，一个小范围业务跑通之后，再逐步扩大迁移范围。

后续值得继续深入的方向有三个：一是基于 TiDB 的跨机房容灾与多活架构设计；二是利用 TiFlash 把更多实时报表场景从数仓搬到在线库；三是结合成本治理做更精细的数据冷热分层。架构迭代不是一次性的项目，而是一个持续演进的过程，选对底座只是第一步。