1. 程式人生 > 資料庫 >阿里規範不建議多表join,可這SQL要怎麼寫啊?

阿里規範不建議多表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的情況呢?是用哪種方案解決,還是說,直接當做沒看到不解決!歡迎留言告訴肥朝。



圖片