引自高性能MySQL：
一、MySQL多表關聯查詢效率高點還是多次單表查詢效率高，為什么？
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層應用自己來合並了。
補充一下：使用join未必效率全低，曾遇到的一個慢sql調優，為方便簡單寫：
// 步驟1
select tableA.id as ids from tableA where age>20; // 步驟二，使用上一步的查詢結果：
select tableB.score from tableB where id in (ids); // 這是一個很常見的查詢，步驟一和步驟二，相當於
select tableB.score from tableB inner join tableA on tableA.id=tableB.id; // 這個效率誰高，看具體情況了。最后測試結果是inner join的效率高。
為什么互聯網公司不讓使用join？
第一：不利於寫操作。執行讀操作時，會鎖住被讀的數據，阻塞其他業務對該部分數據的更新操作(U or D)。如果涉及多個聚合函數（緩存中沒有max or min時），相當於同時鎖住多張表，不能進行讀寫，直接影響其他業務，這影響了系統的整體性能；
第二，不利於維護。業務發生變動時，比如 join 中一張表改了，可能導致系統中原有的 sql 不可用，最終導致基於該 SQL 執行結果的上層顯示失敗（也意味着以往的開發工作已無效）。
如果使用步驟一和步驟二的方式，只需要修改其中一個步驟就行。實際工作中，也就是只需要修改其中的一個service（對應一張表）即可。
既影響性能，又不利於維護，所以我們盡量不要用 join。另外，阿里集團不讓用三張表，是在OLTP場景中，不要一葉障目哦，如果是在復雜分析型OLAP的應用場景中，使用 join 還是非常合適的。
看實際場景：
1、OLTP 比較忌諱多個大表連表查詢，尤其是在未經特別優化的情況下，適當反范式設計可以減少連接查詢提高性能
2、OLAP 中大表多表連接查詢是不可避免的，除了優化索引，最佳實踐就是化整為零，分布計算，一次2-3張表查詢結果放入臨時表
二、《阿里巴巴JAVA開發手冊》里面寫超過三張表禁止join 這是為什么？
1、為什么做這種限制？
打個比方，如果我有無限的錢，我想買個豪華別墅，想買個跑車，想買個直升飛機，那我可以隨便買隨便造；但現實是我沒錢，只能租房住，只能走路上下班。
如果數據庫的性能無限強大，多個表的join肯定是需要的，尤其是復雜的分析型（OLAP）查詢，甚至可能涉及10幾個表的 join，但現實是大部分數據庫的性能都太弱了，尤其是涉及到多表 join 的查詢。
規范一看就是在使用MySQL時的限制（這種規范實際上是迫不得已的限制），做這個限制有兩個原因：
一是優化器很弱，涉及多個表的查詢，往往得不到很好的查詢計划，這塊比較復雜；
二是執行器很弱，只有nested loop join，block nested loop join和index nested loop join。
1）nested loop join 就是分別從兩個表讀一行數據進行兩兩對比，復雜度是n^2
2）block nested loop join 是分別從兩個表讀很多行數據，然后進行兩兩對比，復雜度也是n^2，只是少了些函數調用等overhead
3）index nested loop join 是從第一個表讀一行，然后在第二個表的索引中查找這個數據，索引是B+樹索引，復雜度可以近似認為是nlogn，比上面兩個好很多，這就是要保證關聯字段有索引的原因
4）如果有hash join，就不用做這種限制了，用第一個表（小表）建hash table，第二個表在hash table中查找匹配的項，復雜度是n。缺點是hash table占的內存可能會比較大，不過也有基於磁盤的hash join，實現起來比較復雜。
2、在這種限制下SQL怎么寫？
可是我確實需要兩個表里的數據鏈接在一起啊，我們可以做個冗余，建表的時候，就把這些列放在一個表里
比如：一開始有 student(id, name)，class(id, description)，student_class(student_id, class_id)三張表，這樣是符合數據庫范式的(第一范式，第二范式，第三范式，BC范式等)，沒有任何冗余，
但是馬上就不符合“編程規范“了，那我們可以用一張大表代替它，student_class_full(student_id, class_id, name, description)，這樣name和description可能要被存儲多份，但是由於不需要join了，查詢的性能就可以提高很多了。
任何的規范都是在特定情況下的某種妥協，脫離了這個環境，就不一定成立了。