前言

我們先來看一下阿里開發手冊的描述：

手冊上寫著【強制】，但是我相信很多同學項目里面的代碼都不滿足這個要求。但是關鍵問題是：不用join，這SQL究竟要怎么寫啊！

高性能MySQL

高性能MySQL這本書相信大家都看過，在分解大的查詢這部分提到。

分解關聯查詢，即對每個要關聯的表進行單表查詢，然后將結果在應用程序中進行關聯。下面的這個查詢：

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id=tag.id
JOIN post ON tag_post.post_id=post.id
WHERE tag.tag = 'mysql';

可以分解成下面這些查詢來代替：

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id = 1234;
SELECT * FROM post WHERE post.id in (123,456,567,9098,8904);

但是該方案也會有很明顯的問題，就是in后面的參數可能會過多,可見這個方案的通用性其實非常有限。

知乎

我們看一下知乎數據庫大佬李晨曦的回答。(原地址https://www.zhihu.com/question/56236190/answer/153450286)

建表的時候，就把這些列放在一個表里，比如一開始有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了，查詢的性能就可以提高很多了。任何的規范都是在特定情況下的某種妥協，脫離了這個環境，就不一定成立了。

需要說明的是，這種脫離范式的設計，是互聯網業務在設計高并發表時慣用的做法！

具體問題具體分析

最后，筆者需要多說幾句：具體問題具體分析，規則是死的，人是活的！即使多表Join在阿里規范是強制不允許的，但是筆者依然認為，在比如管理后臺這類并發量很低的業務場景下，依然是可以進行多表Join操作的！

多表Join并不一定是很Low的做法，在錯誤場景下多表Join才是很Low的做法！任何東西都不要一桿子打死！

總結

以上是生活随笔為你收集整理的sql join on 多表连接_阿里规范不建议多表Join，可这SQL要怎么写啊？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。