一般的，像 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 以及聚合函数问题。
随着数据量的增加，业务的复杂度也是成比例的增长，原本你一个小时搞定的技术问题，现在如果你没有经验，可能寸步难行！
标签：中必,Join,跨库,查询,订单,跨表,分表 来源： https://blog.51cto.com/15127565/2664939
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。