数据库架构演进之路：从 MySQL 到 TiDB
随着业务规模不断增长，数据库架构也需要持续演进。从最初的单机 MySQL 到分布式数据库 TiDB，每一步都是为了解决当前阶段面临的性能和容量问题。
一、单机 MySQL
系统初期，用户量和数据量较小，单机 MySQL 就能够满足业务需求。
架构简单，开发成本低，适合快速上线和迭代。
但是随着用户增多，大量查询请求会集中访问数据库，导致 CPU、磁盘 IO 和连接数不断升高，查询性能逐渐下降。
二、MySQL + Redis
当数据库读请求成为瓶颈时，引入 Redis 作为缓存层。
热点数据优先从 Redis 获取，只有缓存未命中时才访问 MySQL，从而显著降低数据库查询压力，提高系统响应速度。
这一阶段主要解决的是数据库读压力问题。
但是写请求仍然全部落在 MySQL 上，因此数据库写入能力并没有得到提升。
三、读写分离
随着业务继续增长，仅依靠缓存已经无法满足需求，于是引入读写分离架构。
主库负责新增、修改和删除操作，从库负责查询操作，通过主从复制同步数据。
这样可以将大量查询请求分散到多个从库，大幅提高系统整体吞吐量。
读写分离解决了查询压力问题，但所有写请求仍然集中在主库上，单机写入能力和存储容量仍然存在瓶颈。
四、历史数据归档
当业务运行多年后，大量历史数据会导致表数据急剧膨胀。
例如订单系统中，用户通常只查询最近几个月或一年的订单，而几年前的数据很少访问。
因此可以将历史数据迁移到历史库或历史表，仅保留近期热点数据在主业务库中。
历史归档能够有效缩小表规模、减少索引体积、提升查询性能，同时降低数据库备份和维护成本。
五、分区表
当单表数据达到数千万甚至上亿级别时，可以利用分区表按时间或业务维度对数据进行逻辑拆分。
例如按照年份或月份划分分区：
2024年数据
2025年数据
2026年数据
查询时只扫描相关分区，从而减少扫描范围，提高查询效率。
不过分区表本质上仍然属于单机数据库，无法解决存储容量和写入能力的上限问题。
六、ShardingSphere 分库分表
当单机数据库无法继续支撑业务规模时，需要进行水平扩展。
通过 ShardingSphere 等中间件，将数据拆分到多个数据库和数据表中存储。
例如：
order_0
order_1
order_2
order_3
数据按照用户 ID 或订单 ID 分散存储到不同节点。
分库分表解决了单机容量限制和写入瓶颈问题，可以支撑亿级甚至百亿级数据规模。
但同时也带来了新的挑战：
跨库查询复杂
跨库事务困难
分页和排序成本增加
扩容需要数据迁移
系统架构和运维复杂度明显提升。
七、TiDB 分布式数据库
当业务规模进一步扩大时，传统分库分表的维护成本会越来越高。
TiDB 作为分布式数据库，将分库分表、数据路由、分布式事务和高可用能力集成到底层系统中。
对于开发人员来说，依然使用标准 SQL 操作数据库，而数据会自动完成分片和分布式存储。
TiDB具备以下特点：
自动分片
自动扩容
分布式事务
多副本高可用
兼容 MySQL 协议
它解决了传统分库分表带来的开发和运维复杂度问题，更适合超大规模数据场景。
100万数据
↓
MySQL
1000万数据
↓
Redis
5000万数据
↓
读写分离
1亿数据
↓
历史归档 + 分区表
10亿数据
↓
分库分表
100亿数据以上、多机房、高可用
↓
TiDB
总结
数据库架构演进的核心目标是不断解决系统增长过程中出现的新瓶颈：
单机 MySQL → Redis缓存 → 读写分离 → 历史数据归档 → 分区表 → 分库分表 → TiDB
其中：
Redis 解决读压力问题；
读写分离解决查询压力问题；
历史归档和分区表解决大表查询问题；
分库分表解决单机容量和写入瓶颈；
TiDB 解决分库分表带来的复杂性问题。
整个演进过程本质上是系统从单机架构逐步走向分布式架构的过程，也是互联网业务规模不断扩张后的必然选择。
