leyu·乐鱼(中国)体育官方网站

　　A,B两个外数据界限十几万，数据界限都不大，单机MySQL够用了，正在单机的根本上要闭系两外的数据，先说一个极度状况，A,B两个外都没有索引，而且闭系是笛卡尔积，那干系合果会爆炸式延长，恐怕到亿级别，这个期间汇集IO成了瓶颈，这个期间两次十万行结果集的拉去恐怕远小于1次亿级其它结果集的拉取，那么将闭结合并拉到service层做更速。但实质营业中通常不会有这么蠢的作为，通常闭系会有维系条款，而且维系条款上会有索引，通常是有一个结果集对比小，拿到这个结果集去另一张外去闭系出其它音讯，假使放到service层去做，最速的格式是，先查A外，取得一个小的结果集，一次rpc，再按照结果集，撮合出B外的查问条款，去B外查到一个结果集，再一次rpc，再把结果集拉回service层，再一次rpc，然后service层做统一，3次rpc，假使用数据库的join，干系合果拉回来，一次rpc，助你省了两次rpc，当然数据库上做闭系更速，对应到数据库便是一次blk nested loop join，这是营业常用状况。

　　可是确实大大批营业都磋商量把这种统一操作放到service层，我以为有几方面商量：

　　第一：单机数据库盘算资源很贵，数据库同时要供职写和读，都须要消磨CPU，为了能让数据库的模糊变得更高，而营业又不正在乎那几百微妙到毫秒级的延时差异，营业会把更众盘算放到service层做，结果盘算资源很好程度扩展，数据库很难啊，于是大大批营业会把纯盘算操作放到service层做，而将数据库当成一种带事件才智的kv体系来操纵，这是一种重营业，轻DB的架构想绪

　　第二：许众庞杂的营业恐怕会因为生长的史乘理由，通常不会只用一种数据库，通常会正在众个数据库上加一层中央件，众个数据库之间还能做毛的join，自然营业会笼统出一个service层，低浸对数据库的耦合。

　　第三：看待少少大型公司因为数据界限宏壮，不得过错数据库举行分库分外，这个题目我正在《阿里为什么要禁用三外以上的join》上也解答过，看待分库分外的操纵，操纵join也受到了许众限定，除非营业也许很好的按照sharding key清楚要join的两个外正在统一个物理库中。而中央件通常对跨库join都援手欠好。举一个很常睹的营业例子，正在分库分外中，要同步更新两个外，这两个外位于差异的物理库中，为了包管数据相同性，一种做法是通过分散式事件中央件将两个更新操作放到一个事件中，但如此的操作通常要加全体锁，本能很捉急，而有些营业也许容忍短暂的数据不相同，奈何做？让它们永诀更新呗，可是会存正在数据写挫折的题目，那就起个依时工作，扫描下A外有没有挫折的行，然后看看B外是不是也没写胜利，然后对这两条闭系记实做厘正，这个期间同样没法用join去达成，只可将数据拉到service层操纵本人来统一了。。。

　　不停思要聊一聊闭于开辟中更发起操纵单外查问+代码层拼装or联外查问的题目，正在开辟中每个同窗的开辟中有各自的民风，笔者正在公司也和少少同事闭于这方面有少少研商。

　　闭于本文，更像是少少一面的睹解，思到什么说什么，肯定有差异的定睹，迎接众人留言，一齐磋商。

　　看似后者查问方法更众了，底本一个手法查问就能出结果，现正在直接酿成三个。可是如此做的好处是：

　　正在实质开辟场景中，正在代码开端开辟阶段（假使摊上一个不太靠谱的产物），营业发作变更，某张外的组织发作变更，很恐怕悉数join查问都变得不成用，庞杂的闭系查问，正在修削时，根基等于推倒重来。

　　可是假使咱们操纵了单外查问，拆成上诉例子中的三个方法，咱们恐怕只须要修削此中的一个方法即可，对比利于保护。

　　这个无须众说，join联外的SQL，根基不太恐怕被复用，可是拆分后的单外查问，譬喻上面例子中，我查问出tab数据，任何地方拼装须要tab数据，我都不须要再次做联系查问，直接操纵。

　　join联外查问，小外驱动大外，通过索引字段举行闭系。假使外记实对比少的话，恶果照样OK的，有时恶果越过单外查问。可是假使数据量上去，众外查问是笛卡尔乘积格式，须要检索的数据是几何倍上升的。此外众外查问索引策画上也磨练开辟者的功底，索引策画分歧理，大数据量下的众外查问，很恐怕把数据库拖垮。

　　比拟而言，拆分成单外查问+代码上拼装，营业逻辑更明晰，优化更容易，单个外的索引策画上也更纯粹。用众几行代码，众几次数据库查问换取这些长处，照样很值得的。

　　正在许众营业中，咱们恐怕对某条记实只须要查问一次，此时何如操纵闭系查问，则不成避免的须要反复地访谒一一面数据，从而恐怕会加剧汇集和内存的消磨。

　　譬喻上面查问中的tag是不常变更的数据，缓存下来，每次查问就能够跳过第一条查问语句。而闭系查问，任何一张外的数据变更都邑惹起缓存结果的失效，缓存诈骗率不会很高。

　　数据库资源对比贵重，许众体系的瓶颈就正在数据库上，许众庞杂的逻辑咱们正在Service做，不正在数据库处置会更好。

　　正在后续数据量上去，须要分库分外时，Join查问更倒霉于分库分外，目前MySQL的分散式中央件，跨库join出现不良。

　　单外查问+代码上拼装相当于解耦，现正在开辟中，咱们经常操纵各样ORM框架，不知晓你的联查orm给你搞成了什么样,你是很难直接优化。

　　以上由来，猛烈推选正在以来的开辟中，尽恐怕的操纵单外查问+代码上拼装的格式。操纵Stream lambda + mybatis plus + lombok， 酸爽！

　　增补一下，操纵join未必恶果全低，曾遭遇的一个慢sql调优，为容易纯粹写：方法一，

　　这个恶果谁高，看完全状况了。结果测试结果是inner join的恶果高。

　　第一，倒霉于写操作。实施读操作时，会锁住被读的数据，障碍其他营业对该一面数据的更新操作(U or D)。假使涉及众个鸠合函数（缓存中没有max or min时），相当于同时锁住众张外，不行举行读写，直接影响其他营业，这影响了体系的全部本能；

　　第二，倒霉于保护。营业发作变更时，譬喻join中一张外改了，恐怕导致体系华夏有的sql不成用，最终导致基于该SQL实施结果的上层显示挫折（也意味着以往的开辟劳动已无效）。

　　假使操纵方法一和方法二的格式，只须要修削此中一个方法就行。实质劳动中，也便是只须要修削此中的一个service（对应一张外）即可。

　　既影响本能，又倒霉于保护，于是咱们尽量不要用join。此外，集团不让用三张外，是正在OLTP场景中。不要一叶障目哦，假使是正在OLAP的操纵场景中，操纵join黑白常适宜的。

　　谢邀。我暂且以为题主说的是内维系。处置内维系一定是放正在数据库上做，毫无疑义。

　　从内维系的角度来讲，数据库平凡会达成2种实施部署。第一种是NESTED LOOP。这种实施部署平凡用于小外闭系，也许最大限定的删除内存开销并尽速返回结果。第二种是HASH。这种实施部署平凡用于小外和大外闭系，或者大外和大外闭系，会有少少内存开销，可是大数据量下的处置速率是NESTED LOOP不成比较的。假使2张外都是十几万条记实的话，数据库的查问优化器该当会遴选HASH JOIN来达成内维系操作。而假使闭系操作放正在操纵里做，险些一齐顺序员都邑遴选2重轮回去达成，这种逻辑是被HASH JOIN完爆的。

　　又有便是放正在操纵层做又有很大的汇集开销，紧要是数据库供职器和操纵供职器之间的开销。明显，从汇集开销的角度来说，也该当把内维系放正在数据库上达成。

　　MySQL的闭系查问写得确实通常，可是，平凡也比放到操纵来做要速十分众。

　　你先要理会一个东西，正在供职器上什么是最速的，汇集磁盘内存CPU，汇集最慢。

　　正在service层统一就会导致，底本1次汇集交互酿成2次(或众次)汇集交互，一定会变慢

　　好了，再清晰下为什么阿里这些至公司会推选不要join外，由于像这种民众是操纵了分库分外的状况，他们join外是受到了许众限定，或者中央件不援手。此中，像这种跨库查问也会展现众次数据库交互的状况，不肯定比拆开成2个(众个)SQL的恶果要高

　　至于其他谜底内中的sql不成复用的状况，我以为你无须商量这种，由于一朝真的数据库外策画发作修削，join外的字段都变了，假使不改sql，那就代外要去改service代码，横竖都遁然而

　　赞同放操纵里写闭系的，都是数据库只知外相的操纵层顺序员吧？要拓展常识面啊，别让人乐掉大牙。

　　举个例子你就理会了。譬喻，要统计2017年每个月的用户访谒分散量（没访谒的占比，访谒1-5次的占比，访谒6-10次的占比……）。这是一个纯粹的维系题目（用户外左维系访谒外）。用众外维系，你本能够从供职器端取回12行数据的（1-12月），结果你用了两次单外查问，从以上两个内外各取回了数万甚至上百万条数据，然后去做轮回……这种顺序员是脑残吧？

　　假使换一个温和点的例子，一个往还内外有userid，另一个内外有userid和username，你须要列出往还外的username。用数据库众外闭系恶果也远远比单外查问然后本人写闭系强，强得众得众。假使Mysql这种没有hash join的维系弱鸡，你操纵层再奈何写DIY的维系逻辑，也比然而它。这和index无闭。

　　唯有0.001%的状况，也便是访谒量极大的网站（微博，贴吧），为包管写入恶果，会限定sql查问的资源（闭上archive/log，用nosql，用memcache之类的众层存储……），当然这是此外一个题目了。

　　阿里规约内中也没有说不行用join,而是说不要越过两次，何如删除join,汇总下众人说的：

　　2.用存储历程。阿里清楚禁止。一面操纵也是切齿痛恨，除非出于对数据的偏护，不发起用存储历程。视图更是脱了裤子放屁。

　　3.增添数据冗余，把闭系查问的字段都加到单外。差错便是数据组织变更经常，数据处置本钱增添，更首要的数据相同性弄欠好容易出bug。

　　4.创筑索引外。这原本也是冗余策画，然而不是单外上加，而是此外创筑一个外把闭系字段鸠集起来乐鱼体育。数据相同性的题目照样有，好正在不影响单外。

　　然而要我说，咱们又不是阿里，中小型项目，费那劲干嘛，join就完了，别说两次了，10次的我也睹过，查问慢点就慢点吧，客户都没说啥，你何须呢

　　于是我发起，假使小于3张外，操纵join，假使假使大于3张外，先拆开，再闭系。

　　闭系查问，索引筑好，每次查问外面套分页，写得好的话呼应速率该当都不会到毫秒吧

　　正在数据量不大的状况下众外维系查问和众次单外查问的恶果差不众。假使数据量足够大，那一定是众次单外查问的恶果更高。正在少少大的公司内中，都邑禁用众外维系查问，理由便是一朝数据量足够大的期间众外维系查问恶果会很慢，并且倒霉于分库分外的查问优化。