阿里規範不建議多表join，可這SQL要怎麼寫啊？

前言

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

手冊上寫着【強制】，可是肥朝相信不少同窗項目裏面的代碼都不知足這個要求。可是關鍵問題是，不用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的狀況呢？是用哪一種方案解決，仍是說，直接當作沒看到不解決！歡迎留言告訴肥朝。

---