一般的，像 MySQL 单表数据在 2000W 的时候就要考虑分库分表了。因为，在往上，查询效果下降的就比较明显了。
然而，分表好分，分起来也很爽。但是分表之后的跨表 Join，或者合并查询就显得很头痛了。今天，我们一起来看看，常见的几个跨表 Join 问题。
1、字典表或全局表的多表备份，避免跨表跨库 Join 查询。
关系型数据库的一大特点就是关联查询。采取分库分表，本来就是分算查询。我先说一种简单的情况，就是字典表。数据本身很少，你对它进行分表吧，数据量太小，根本没必要。不分表吧，关联的表，比如，订单表关联的字典表就需要 Join。如果你分表了，那么就会存在跨表关联问题，而且数据量小，业务复杂度增加。不分表分库，那可能数据就集中在同一个库和表中，Join 起来，大量的查询流量可能集中到某一个库中，反而可能会拖垮。
所以，针对字典表或其他全局表。为了避免跨库 join 查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。
2、反范式设计，避免跨库 Join 查询。
这种设计在电商中很常见。比如，我有一个订单表，订单中的每条记录都会关联着卖家的 id 和卖家的 Name。这样做的好处是，很多时候，显示订单中卖家信息时，我不需要去跨表跨库 Join。
3、合理的业务设计，避免跨表跨库查询。
这类问题，最常见的就是我的订单。我要查我所有的订单时候，我希望一张表就搞定了，不需要跨表。也就是说，设计的时候，尽量把同一个用户的订单放到同一张表中。分表的时候，考虑根据用户的 id 分。
4、借助离线计算、流式技术避免跨表跨库查询。
我现在列举一个报表查询的例子。这种情况下，可能就需要跨 N 个表了，而且是没办法避免的。但是我们从设计上，我们要尽量避免 Join 的。如果有多个 join 的，要么是设计不合理，要么是技术选型有误。
报表类的查询实时性要求又不高，所以可以查用离线分析等手段。报表类的系统在传统 BI 时代都是通过 OLAP 数据仓库去实现的，现在则更多是借助离线分析、流式计算等手段实现，而不该向上面描述的那样直接在业务库中执行大量 join 和统计。
以上，4 点，我讲的很简单。其实跨表跨库会带来很多问题。比如，事务问题；如果不跨表很简单，一个注解就可以搞定，但是分表后就比较麻烦了。其他的还有跨节点的 count，order by，group by 以及聚合函数问题。
随着数据量的增加，业务的复杂度也是成比例的增长，原本你一个小时搞定的技术问题，现在如果你没有经验，可能寸步难行！