感謝作者的貢獻
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層應用自己來合併了。。。
MySQL 子查詢和多表聯查
1 多表聯查 使用多表聯查的場景，有些時候資料在不同的表中，這個時候我們就需要用到mysql中的多表聯查。2 多表聯查概念 將兩個或兩個以上的表按某個條件連線起來，從而選取需要的資料。多表聯查是同時查詢兩個或兩個以上的表時使用的。3 多表聯查分類 1.內連線查詢 內連線查詢使用關鍵字join或cro...
MySQL單錶多次查詢和多表聯合查詢，哪個效率高？
很多高效能的應用都會對關聯查詢進行分解。簡單地，可以對每個表進行一次單錶查詢，然後將結果在應用程式中進行關聯。例如，下面這個查詢 select from tag join tag post on tag post.tag id tag.id join post on tag post.post id...
mysql兩表聯查和內聯 MySQL的多表聯查
如 查詢stu表中年齡最大的是誰？mysql select from stu where age select max age from stu mysql select from stu where age in select max age from stu 子查詢結果是多條時使用in查詢 id...