为什么选择 MySQL？
在实际架构选型中，我们常面临为何在众多数据库中倾向于选择 MySQL 的疑问。早期淘宝网采用 LAMP 架构（Linux + Apache + MySQL + PHP），受限于当时 PHP 不支持数据库连接池且商业方案成本高昂，核心业务随后改用 Java 重写。虽然一度引入 Oracle 配合 iBatis，但运行在 IBM 小型机上导致成本激增。最终系统回归 MySQL，因其是首个在 Linux 下稳定运行的数据库，集群性能优异且对服务器资源要求较低。如今，包括京东、新浪在内的多家互联网企业在大数据处理场景下也广泛采用 MySQL，验证了其在高并发与海量数据处理上的可行性。
什么是数据切分？
数据切分（Sharding）是指通过特定规则，将原本存放在单一数据库中的数据分散存储到多个数据库或主机上。这一机制的核心目的是降低单台设备的负载压力，同时提升系统的整体可用性——当某台设备发生故障时，仅影响部分数据而非全部服务。
根据切分规则的不同，主要分为两种模式：
- 垂直切分：按表或 Schema 划分，将不同业务模块的表拆分到不同的数据库实例上。
- 水平切分：按表中数据的逻辑关系划分，将同一张表的数据行拆分到多台数据库实例上。
垂直切分还是水平切分？
垂直切分的优势在于规则简单、实施方便，特别适合业务耦合度低、逻辑清晰的系统。在这种架构下，不同业务模块的表可以独立部署，对应用程序侵入性较小，维护成本也相对较低。
相比之下，水平切分更为复杂。由于需要将同一张表的数据行分布到不同库中，应用层需要处理更复杂的拆分规则，后期数据迁移和维护的难度也会相应增加。
在系统设计初期，如果垂直切分能满足需求，应优先选择该方案。若仍无法应对增长压力，则需考虑垂直与水平切分联合使用。此时务必仔细斟酌切分规则，因为不同的规则将直接决定未来的维护成本，一切应以符合实际业务需求为准。
为什么需要数据切分？
驱动数据切分的核心原因通常有两点：数据量过大或并发过高。当数据库无法有效支撑客户端请求时，就需要引入切分技术。
试想一下，数亿级的 QQ 号、海量的微博信息或微信聊天记录，绝不可能存放在单张表或单个数据库中。如此庞大的数据规模必须依赖切分技术来管理。此外，切分不仅解决存储瓶颈，也能缓解高并发带来的性能压力。
例如，针对聊天记录业务，可以先利用垂直切分将其与其他业务隔离，优化访问路径；再结合水平切分，按用户 ID 将数据分散存储，确保用户读取自身记录时的效率。即便经过上述处理，若数据量依然巨大，还可根据业务特性进行更深度的切分。通常情况下，垂直与水平切分的组合策略足以解决大部分分布式数据库面临的挑战。
