分库分表正在被淘汰

前言

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库，那么NewSQL 这么牛，分布库分表还有意义吗？

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将“分库分表”的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

1. 数据库的操作变得复杂

   • 跨库 JOIN 几乎不可行：原本简单的多表关联查询，因为表被分散到不同库甚至不同机器上，变得异常困难。通常需要拆成多次查询，在应用层进行数据组装，代码复杂且性能低下。
   • 聚合查询效率低下：COUNT(), SUM(), GROUP BY, ORDER BY 等操作无法在数据库层面直接完成。需要在每个分片上执行，然后再进行合并。
   • 分页问题：LIMIT 20, 10 这样的分页查询会变得非常诡异。你需要从所有分片中获取前30条数据，然后在应用层排序后取第20-30条。页码越大，性能越差。

2. 设计上需要注意的问题

   • 分片键（Sharding Key）的选择：如果前期没有设计好，后期数据倾斜比较严重
   • 全局唯一ID需要提前统一设计，规范下来
   • 分布式事务问题，需要考虑使用哪种方式去实现（XA协议，柔性事务）

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足（分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。 当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库，采用存储计算分离架构，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。
• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。
• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。
• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。
• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。
• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。
• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数
• 触发器
• 事件
• 自定义函数
• 全文索引（计划中）
• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）
• 查询计划的解释结果
• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

1. 数据量大且增长迅速的OLTP场景：当单机MySQL容量或性能遇到瓶颈，且数据量达到TB级别时，TiDB的水平扩展能力能有效解决问题。
   例如，当业务数据量预计将超过TB级别，或并发连接数超过MySQL合理处理范围时。
2. 实时HTAP需求：需要同时进行在线事务处理和实时数据分析的场景。
   传统方案需要OLTP数据库+OLAP数据库+ETL工具，TiDB的HTAP能力可简化架构，降低成本和维护复杂度。
3. 金融级高可用要求：对系统可用性和数据一致性要求极高的金融行业场景。
   TiDB的多副本和自动故障转移机制能确保业务连续性和数据安全。
4. 多业务融合平台：需要将多个业务数据库整合的统一平台场景。
   TiDB的资源管控能力可以按照RU（Request Unit）大小控制资源总量，实现多业务资源隔离和错峰利用。
5. 频繁的DDL操作需求：需要频繁进行表结构变更的业务。
   TiDB的在线DDL能力在业务高峰期也能平稳执行，对大表结构变更尤其有效。

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

1. 中小规模数据量：数据量在百万级以下，且未来增长可预测。
   在这种情况下，MySQL的性能可能更优，且总拥有成本更低。
2. 简单读写操作为主：业务以点查点写为主，没有复杂的联表查询或分析需求。
3. 需要特定MySQL功能：业务依赖存储过程、触发器、全文索引等TiDB不支持的功能。
4. 资源受限环境：硬件资源有限且没有分布式数据库管理经验的团队。
   MySQL的运维管理相对简单，学习曲线较平缓。

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：

4 迁移注意事项

如果决定从MySQL迁移到TiDB，需要注意以下关键点：

1. 功能兼容性验证：检查应用中是否使用了TiDB不支持的MySQL功能，如存储过程、触发器等。
2. 自增ID处理：将AUTO_INCREMENT改为AUTO_RANDOM以避免写热点问题。
3. 事务大小控制：注意TiDB对单个事务的大小限制（早期版本限制较严，4.0版本已提升到10GB）。
4. 迁移工具选择：使用TiDB官方工具如DM（Data Migration）进行数据迁移和同步。
5. 性能测试：迁移前务必进行充分的性能测试，特别是针对业务关键查询的测试。

5 总结

TiDB和MySQL是适用于不同场景的数据库解决方案，没有绝对的优劣之分。MySQL是优秀的单机数据库，适用于数据量小、架构简单的场景；数据量大了之后需要做分库分表。而TiDB作为分布式数据库，专注于解决大数据量、高并发、高可用性需求下的数据库瓶颈问题，但是成本也是非常的高