两三年前，数据库容量告急，团队拍板做分库分表。按用户 ID 把 16 个库拆好，数据均匀分布，查询和写入性能明显好转。当时所有人都觉得做了一个正确的决定。
但现在，当初的设计正在变成负担：每次需求变更都要考虑分片规则，每个新同事都要花大量时间理解路由逻辑，每次线上问题排查都要同时盯 16 个库的日志。
分库分表最大的特征就是：开始容易，维护难。 难在哪里？有六个层面。
跨库查询：一个 JOIN 变成了一场工程
没拆库之前，查一个用户的订单列表加关联的商品信息，一句 SQL 就搞定。拆完之后，订单在 A 库，商品在 B 库，这句 JOIN 跑不通了。
关联查询、聚合统计更加棘手——拆库之前一个 SUM 就行，拆完之后需要分别从 16 个库各自 SUM，再在应用层加总。如果有 GROUP BY、HAVING、ORDER BY，改造的复杂度又会上升一个台阶。
分布式事务：一致性保障是硬骨头
拆完之后，订单在 A 库，库存可能在 B 库，本地事务保证不了跨库的一致性。通常需要引入分布式事务方案，每种都有代价：
- 两阶段提交对性能影响大，任一参与者响应慢就会拖慢整个事务。
- 基于消息的最终一致性可以实现，但应用层需要编写消息发送、消费、重试、幂等处理等大量逻辑。
- TCC 补偿模式要求每个业务操作都实现 Try、Confirm、Cancel 三个方法，业务侵入性强，调试和排错困难。
表结构变更：DDL 操作风险被放大
给一张表加个字段，执行一次 ALTER TABLE 就行。分库分表之后，同样的操作需要在 16 个库上同时执行。如果一个库成功、另一个库失败，就会出现表结构不一致。在大表上执行 DDL 本身就是高风险操作，分库之后，这个风险被放大了 N 倍。
数据迁移与重新分片：最难的操作
分片规则不再适用——某个业务线用户量暴增，对应分片的数据量远超其他分片。重新分片意味着要把现有数据按照新的规则重新分配，涉及全量数据的读取、计算和写入。很多团队宁可硬扛不均衡的分片，也不愿意冒重新分片的风险。
运维复杂度成倍增长
监控一个实例变成监控 16 个。备份策略要协调 16 个库的执行时间。故障排查时需要在多个库之间来回比对日志和状态。如果使用了中间件，中间件本身也成了新的单点。
团队认知负担
代码中充斥着分片路由逻辑：根据用户 ID 取模决定查哪个库、批量查询时按分片分组再并行执行。新成员需要花大量时间理解这些逻辑，每一次代码 review 都要额外关注分片相关的问题。
为什么会这样？
分库分表的本质是把数据分布的复杂度从数据库层转移到了应用层。容量问题确实解决了，但分布式系统的固有问题并没有消失，只是从数据库的内部实现变成了应用层需要自己处理的问题。
有没有不需要应用层处理这些复杂度的方案？
如果把数据分布和路由的复杂度交回给数据库本身，应用层就不需要感知这些细节。分布式数据库在底层自动完成数据分片、路由、分布式事务和 rebalance，对应用层来说，看到的仍然是一张"普通"的表。TiDB 和平凯数据库（TiDB 企业版）是这类分布式数据库的典型代表之一，SQL 语法与传统数据库兼容，无需编写分片路由逻辑，也无需手动处理分布式事务的复杂性。对于正被分库分表维护困境困扰的团队来说，这是一种从根源上消除复杂度的方向。