MySQL是大型架构核心，下面我详解MySQL分库分表@mikechen
MySQL分库分表
在互联网业务快速增长的背景下，单机 MySQL 往往会很快遇到性能瓶颈。
主要表现为数据量过大、单表查询变慢、写入压力过高、索引膨胀以及扩容困难。
为了应对这些问题，分库分表成为高并发系统中常见且有效的数据库扩展方案。
MySQL分库分表原理
分库分表的核心思想，是“横向拆分”数据，而不是简单提升单机性能。
所谓分库，是将数据分散到不同的数据库实例中；
分表则是在同一数据库或不同数据库中，将数据拆分到多个表中。
分库分表通常有两类：
垂直拆分
按业务拆分，例如用户库、订单库、商品库分离。
优点是业务边界清晰，耦合度低。
缺点是跨库关联查询复杂。
水平拆分
按某种规则将同一张表的数据拆到多个表或库中。
常见规则包括：按用户 ID 取模、按时间范围、按地区编码等。
优点是分散数据量和压力。
缺点是数据访问路径复杂，事务和查询能力受限。
MySQL分库分表实战
以电商订单系统为例，订单表随着业务增长迅速膨胀，单表数据量达到数亿级。
系统需要支持高并发下单、查单、支付回调和订单状态流转。
此时可采用如下方案：
第一步：评估拆分必要性
先判断是否真的需要分库分表。很多场景下，索引优化、读写分离、缓存和归档策略就能解决问题。只有在单库单表已接近瓶颈时，才考虑拆分。
第二步：确定拆分规则
选择稳定且高频的分片键，常见为 user_id、tenant_id 或订单号中的业务字段。拆分规则一旦上线，后期变更成本很高，因此前期设计必须谨慎。
第三步：设计表结构
拆分后的每个分片表结构应保持一致，避免后续维护困难。同时要控制单表字段数量和索引数量，减少索引膨胀。
第四步：引入中间件
可使用分库分表中间件完成 SQL 路由和改写，例如 ShardingSphere 等。中间件能降低业务侵入，但也要注意其 SQL 支持范围和性能开销。
第五步：数据迁移
历史数据迁移通常是最复杂的一步。一般做法包括：
- 先全量迁移历史数据
- 再通过双写或 binlog 增量同步
- 最后切流验证
- 逐步下线旧库
迁移过程中必须做好校验、回滚和灰度发布。