在我们日常的生产环境中，一旦数据库出现性能瓶颈，很自然就会想到分库分表。可以按照取模、一致性哈希或者时间点来分区等等。总的来说，操作起来还算容易，尤其是借助一些中间件，像 MyCat ，拆分动作相对容易。
然而，在享受性能提升的同时，分库分表也带来了诸多难题。比如大家在评论区提到的，分库分表之后怎么去 join 。一般情况下，不建议像单库单表那样进行 join 操作，应避免这种查询。常规做法可以采用字段冗余，这样有些字段就无需通过 join 去查询。
还会遇到分布式 ID 的问题。不能再像以前用 MySQL 的自增 ID ，因为在插入记录时，不同的库和表会出现冲突，所以需要一个全局的 ID 生成器，系统需要额外可靠的分布式 ID 生成器服务，而且必须可靠，否则宕机超时可能成为新的性能瓶颈。
常见的分布式 ID 生成策略有多种，比如 UUID ，用得较多，实践方便，但没啥辨识度，看起来像乱码。还可以用 Redis 的 incr 函数，但 Redis 要确保可靠性，一旦出现故障重启，数据可能丢失，可能重新计算，导致出现重复 ID 。像雪花算法、美团的 Leaf 等也是常见的策略。
再有，分库分表后可能会遇到扩表场景。一旦数据表不够用要重新分表，就面临将几千万甚至几亿的数据重新刷盘，工作量可不小，得重视。还有让人头疼的分布式事务，这是分库分表绕不过的坎，因为涉及同时更新多个数据库多个数据表，如何保证要么同时成功要么同时失败是个亟待解决的问题。常见方案有两种，要么是 XA ，要么是 TCC 。目前主流方案是 TCC ，先锁定资源，然后再 confirm 、commit 。但不管是 XA 还是 TCC ，实现起来都不容易，很复杂，不太可能自己手写实现，其实可以使用一些开源框架，比如 Fubaochang 的 TTA 或者 Baidu 的 TCC 等等。
总结一下，如果没到那个必要程度，尽量不要尝试分库分表，它带来的问题太多了。如果没有相应的技术实力，可能会拖垮整个项目。
