分布式数据库时代，分库分表是否仍有必要？

一、分布式数据库与分库分表的核心差异

1. 架构层级对比
   分布式数据库（如TiDB、CockroachDB）是数据库引擎层面的分布式实现，通过Raft/Paxos协议保证数据一致性，天然具备水平扩展能力。而分库分表是应用层逻辑分片，需要开发者自行处理跨节点事务和查询路由。

2. 透明性差异
   分布式数据库提供完整的SQL兼容性和ACID事务保证，对应用透明。分库分表则需要处理分片键选择、跨库JOIN等复杂问题，典型方案如ShardingSphere需要额外中间件支持。

3. 扩展粒度区别
   分布式数据库通常以Region/Zone为单位扩展，分库分表则以表或库为最小单位。例如MongoDB分片集群可以精确到collection级别扩容。

二、必须考虑分库分表的典型场景

1. 超大规模单表场景
   当单表数据超过分布式数据库的推荐上限时（如TiDB建议单Region不超过96GB），仍需通过分表进一步拆分。某电商平台在TiDB上对订单表按用户ID哈希分表，使单表数据控制在50GB以内。

2. 多租户隔离需求
   SaaS系统需要物理隔离不同租户数据时，分库仍是有效手段。例如Salesforce采用分库策略保证企业级客户的数据独立性。

3. 混合存储需求
   热数据存分布式数据库+冷数据归档到传统分库的架构很常见。某金融系统将3年内交易数据存TiDB，历史数据按年份分库存储。

-- 分库分表与分布式数据库混合使用示例
CREATE TABLE orders_2023 (id BIGINT PRIMARY KEY,...) 
PARTITION BY RANGE (YEAR(create_time)) (
    PARTITION p2023 VALUES LESS THAN (2024) 
    ENGINE=TIDB,
    PARTITION p2022 VALUES LESS THAN (2023) 
    ENGINE=InnoDB
);

三、无需分库分表的适用情况

1. 中小规模业务
   数据量在TB级以下时，现代分布式数据库（如AWS Aurora）完全能满足需求。测试显示单Aurora实例可支撑5万TPS的OLTP负载。

2. 强一致性要求系统
   银行核心系统选用Spanner架构的数据库时，其全局时钟协议已解决跨节点一致性问题，额外分片反而增加复杂度。

3. 实时分析场景
   Snowflake等云数仓采用存储计算分离架构，自动处理数据分布，用户无需关心物理分片。

四、架构选型决策模型

评估维度	分布式数据库优势场景	分库分表优势场景
数据规模	<100TB	>100TB且存在局部热点
开发成本	要求快速迭代	有专业DBA团队
事务复杂度	跨实体事务频繁	单分片事务为主
查询模式	多表关联复杂查询	简单主键查询为主

五、最佳实践建议

1. 渐进式演进策略
   初期使用分布式数据库快速上线，待单表超过5000万行时再评估分表。某社交App先用MongoDB Atlas，用户破亿后对消息表进行哈希分片。

2. 混合架构设计
   核心交易用分布式数据库保证一致性，日志类数据采用分库分表降低成本。参照阿里巴巴「单元化」架构设计思路。

3. 监控关键指标
   重点关注：分布式事务冲突率、跨节点查询延迟、存储节点水位差。当P99延迟>100ms时应考虑数据重分布。

六、未来发展趋势

1. 自动分片技术成熟
   YugabyteDB的Tablet自动分裂、OceanBase的LSM-Tree分层存储等技术正在模糊两者的界限。

2. 云原生数据库演进
   AWS Aurora Limitless、Google Spanner的细粒度弹性扩展将逐步替代人工分片需求。

3. 新硬件的影响
   PMEM持久内存和RDMA网络使得单节点可处理更大数据集，可能改变分布式架构的平衡点。

总结来看，分布式数据库解决了80%的扩展性问题，但在极端场景和特定需求下，分库分表仍是不可或缺的补充方案。技术选型应基于实际业务特征，采用「分布式数据库为主，分库分表为辅」的务实策略。