【架构实战】TiDB分布式数据库从MySQL到NewSQL的迁移一、MySQL的尽头是TiDB2021年业务量翻了5倍MySQL分库分表也扛不住了。当时的技术债16个MySQL库128张分表运维成本爆炸DDL要选窗口期怕锁表影响线上分片键用user_id但运营团队天天要按order_status、product_id查扩容要rehash每次都是心惊胆战分布式事务用Seata补偿逻辑越写越复杂CTO一句话决策考察NewSQL目标是像用MySQL一样用分布式数据库。对比了TiDB、OceanBase、CockroachDB后选择了TiDB——理由很简单兼容MySQL协议DBA团队学习成本最低。二、TiDB架构详解2.1 三大核心组件┌─────────────────┐ │ TiDB Server │ ← SQL层无状态可水平扩展 │ (SQL解析优化) │ └────────┬────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌─────────▼─────┐ ┌─────▼─────┐ ┌─────▼─────────┐ │ PD │ │ TiKV │ │ TiFlash │ │ (调度元数据) │ │ (行存储) │ │ (列存储) │ │ │ │ RocksDB │ │ ClickHouse │ └───────────────┘ └───────────┘ └───────────────┘2.2 组件职责组件职责类比MySQL关键特性TiDB ServerSQL解析、优化、执行Server层无状态随便扩PD集群调度、元数据、TSO无分布式特有Raft Leader选举TiKV行存储引擎OLTPInnoDB数据分Region自动分裂TiFlash列存储引擎OLAP无实时同步TiKVHTAP核心2.3 Region分裂与调度数据以Region为单位管理默认96MB自动分裂和调度T1: Region1 [key: 000 ~ 100] 大小50MB T2: Region1 [key: 000 ~ 100] 大小100MB → 自动分裂 T3: Region1 [key: 000 ~ 050] Region2 [key: 051 ~ 100] T4: PD调度RebalanceRegion2迁移到其他TiKV节点这就是TiDB扩展性的核心不需要分库分表数据自动分片、自动均衡。三、从MySQL迁移到TiDB3.1 兼容性评估-- TiDB兼容的MySQL特性大部分SELECT,INSERT,UPDATE,DELETEJOIN,SUBQUERY,UNIONINDEX,VIEW,TRIGGERAUTO_INCREMENT-- 需要注意的差异-- 1. 不支持存储过程、函数TiDB 5.0开始支持但有限制-- 2. 不支持外键分布式场景下性能差-- 3. 事务大小限制单事务不超过100MB-- 4. 自增ID仅保证唯一不保证连续3.2 数据迁移工具——TiDB Lightning# 1. Dumpling导出MySQL数据./dumpling\-hmysql-host-P3306\-uroot-ppassword\-Bmydb\-o/data/export\--filetypesql\--threads16# 2. TiDB Lightning导入./tidb-lightning\-configtidb-lightning.toml\-check-requirementsfalse# tidb-lightning.toml[lightning]levelstrictfile/tmp/lightning.log[tikv-importer]backendlocal# 本地导入模式性能最高[mydumper]>/data/export[tidb]host127.0.0.1port4000userrootpassword3.3 SQL改写实战-- BEFORE: MySQL分库分表后按user_id查-- 应用层需要根据 user_id % 16 路由到具体分片SELECT*FROMt_orderWHEREuser_id12345;-- AFTER: TiDB直接查不需要分片逻辑SELECT*FROMt_orderWHEREuser_id12345;-- TiDB自动根据user_id的key范围路由到对应Region-- 更爽的是按order_status跨分片查询-- MySQL时代需要遍历16个库-- TiDB直接查PD全局路由SELECT*FROMt_orderWHEREstatusPAIDLIMIT100;3.4 迁移checklist┌── 迁移前 ──────────────────────────────┐ │ □ 评估SQL兼容性存储过程、外键等 │ │ □ 识别热点表规划预切分Region │ │ □ 全量数据导出Dumpling │ │ □ 建立增量同步TiCDC │ │ □ 准备回滚方案MySQL备份保留7天 │ ├── 迁移中 ──────────────────────────────┤ │ □ 全量导入Lightning │ │ □ 数据校验sync-diff-inspector │ │ □ 灰度切流5% → 20% → 100% │ │ □ 监控QPS、延迟、错误率 │ ├── 迁移后 ──────────────────────────────┤ │ □ 观察3天确认稳定 │ │ □ 优化慢查询ANALYZE TABLE │ │ □ 调整GC策略tidb_gc_life_time │ │ □ 清理MySQL数据 │ └────────────────────────────────────────┘四、TiDB性能优化4.1 热点问题——最常见的问题-- 问题自增主键的INSERT全部写入同一个RegionINSERTINTOorders(user_id,amount)VALUES(?,?);-- 所有新数据的key聚集在一个Region造成写热点-- 解决方案1SHARD_ROW_ID_BITS打散自增IDALTERTABLEorders SHARD_ROW_ID_BITS4;-- 解决方案2AUTO_RANDOM推荐CREATETABLEorders(idBIGINTPRIMARYKEYAUTO_RANDOM,user_idBIGINT,amountDECIMAL(12,2));-- 解决方案3UUID替换自增IDCREATETABLEorders(idVARCHAR(36)PRIMARYKEYDEFAULT(UUID()),user_idBIGINT,amountDECIMAL(12,2));4.2 慢查询优化-- TiDB特有的执行计划查看EXPLAINANALYZESELECT*FROMordersWHEREuser_id12345;-- 关注点-- cop_task: TiKV上的执行时间存储层-- root_task: TiDB上的执行时间SQL层-- 如果cop_task很多说明大量数据从TiKV拉到TiDB处理需要优化索引-- 统计信息更新ANALYZETABLEorders;-- TiDB依赖统计信息优化查询定期UPDATE非常重要4.3 HTAP实战OLTP OLAP共存-- TiFlash自动同步TiKV数据AP查询自动路由到TiFlash-- 无需额外配置优化器自动选择EXPLAINSELECTcategory_id,SUM(amount)FROMordersWHEREcreate_time2025-06-01GROUPBYcategory_id;-- 如果看到 cop[tiflash]说明走了列存引擎-- 0.3秒完成8亿行数据聚合五、运维最佳实践# TiUP集群拓扑生产环境最低配置tidb_servers:-host:10.0.1.1-host:10.0.1.2-host:10.0.1.3# 3台TiDB Serverpd_servers:-host:10.0.1.4-host:10.0.1.5-host:10.0.1.6# 3台PD必须奇数tikv_servers:-host:10.0.2.1-host:10.0.2.2-host:10.0.2.3# 至少3台TiKV3副本data_dir:/data/tikv六、总结迁移TiDB最大的感受是DBA终于不用半夜起来调分库分表了。核心价值MySQL兼容协议迁移成本低团队学习曲线平缓自动分片告别手动分库分表的运维噩梦HTAP能力OLTPOLAP一个引擎搞定不需要T1数据同步水平扩展只需加机器数据自动rebalance注意事项TiDB适合大数据量TB级别数据量小就别折腾存储过程和复杂事务场景需要评估兼容性自增ID要换成AUTO_RANDOM避免写热点运维团队要理解Raft协议和Region概念一句话如果MySQL分库分表让你痛不欲生TiDB值得你认真考虑。个人观点仅供参考