分库分表带来的问题
分库分表确实是应对数据量增长、提升数据库性能和可用性的重要手段，但它绝非银弹，会引入一系列显著的复杂性和挑战。以下是我认为分库分表带来的主要问题：
开发复杂度显著增加：
SQL 支持受限： 许多在单库单表上简单高效的 SQL 语句变得难以执行或效率极低。
跨分片 JOIN： 关联查询涉及多个分片时，需要在应用层手动聚合数据（多次查询、内存 JOIN），或者使用冗余数据（如宽表、数据异构），逻辑复杂且性能差。
跨分片排序分页：
ORDER BY ... LIMIT offset, count在跨分片时无法直接使用。需要先在每个分片排序取数据（可能取大量数据），再到应用层合并、排序、分页，效率低下且资源消耗大。函数计算受限：
SUM(),COUNT(),MAX(),MIN()等聚合函数需要先在每个分片执行，再到应用层合并结果。全局唯一序列 ID： 无法依赖数据库自增 ID。需要引入分布式 ID 生成方案（如 Snowflake, UUID, Redis/ZooKeeper 序列号，数据库号段等），增加复杂度和维护成本。
分片键选择至关重要且难以更改：
分片键的选择直接影响数据分布的均匀性和查询效率（是否能路由到单一分片）。一旦选定并实施，后期修改分片策略的成本极高（需要数据迁移）。
业务查询模式必须尽可能围绕分片键设计，否则容易导致广播查询（扫描所有分片），性能急剧下降。
事务管理复杂化（分布式事务）：
原本在单一数据库内简单的 ACID 事务，在跨多个数据库实例/分片时变得异常复杂。
实现强一致性需要引入性能开销大的分布式事务协议（如 2PC/3PC），或者采用最终一致性（BASE）模式，这对应用逻辑设计提出了更高要求（补偿机制、幂等性）。XA事务性能较差，通常不被推荐。
数据迁移与扩容困难：
扩容（Resharding）痛苦： 当现有分片容量不足需要增加分片数量时，通常需要重新划分数据范围，并进行大规模数据迁移。这个过程复杂、耗时长、风险高（数据一致性、业务停机或性能影响）。
迁移工具与策略： 需要精心设计迁移工具（如双写、增量同步）和切换策略（如灰度切换、数据校验），确保平滑过渡和数据安全。
运维复杂度激增：
部署与配置管理： 需要管理部署大量的数据库实例和表，配置（连接池、权限、参数）管理、版本升级、备份恢复策略都变得更加繁琐。
监控与告警： 监控对象数量剧增，需要统一的监控平台来汇总和分析各个分片的性能指标（CPU、内存、IO、慢查询、连接数等），设置合理的告警阈值和策略，定位问题更困难。
故障排查难度加大： 当出现性能问题或数据不一致时，需要跨多个节点进行排查，定位根因的路径更长、更复杂。一个慢查询可能影响的是多个分片。
备份与恢复： 备份多个数据库实例的协调性和一致性是个挑战。全量恢复或恢复到某个时间点（PITR）的操作复杂度大大增加。
资源成本上升： 需要更多的服务器、存储、网络资源和数据库授权（如果是商业数据库），运维人力成本也会增加。
特定功能的挑战：
全局唯一约束： 在分片环境下实现某个字段（非分片键）的全局唯一性非常困难且低效（通常需要引入全局协调者或唯一索引服务）。
数据倾斜： 如果分片键选择不当或业务数据分布不均，可能导致某些分片数据量或负载远高于其他分片（热点），形成瓶颈，抵消了分库分表的优势。
历史数据与归档： 管理冷热数据、归档历史数据到其他存储系统的策略在分片环境下更复杂。
数据库工具兼容性： 很多针对单实例的数据库管理工具、DBA 经验在分片环境下可能不完全适用或需要改造。
注意：
谨慎评估，非必要不拆分。
精心设计分片策略（分片键、路由算法），这是成功的关键。
尽量使用成熟的分库分表中间件 (如 ShardingSphere, MyCAT, Vitess)，它们封装了大部分复杂性（SQL 解析、路由、结果归并、分布式事务支持等）。
应用设计遵循分片意识： 业务逻辑尽量围绕分片键设计，避免或减少跨分片操作。
建立强大的运维监控体系。
充分测试，特别是扩容、故障切换等场景。