原文連結：https://mp.weixin.qq.com/s/NeR8hNd0zrPflYqQd_6i-w

前言

一直想要聊一聊關於開發中更建議使用單表查詢+程式碼層組裝 or 聯表查詢 的問題，在開發中每個同學的開發中有各自的習慣，筆者在公司也和一些同事關於這方面有一些探討。

對比

在實際開發中，我們不可避免的要關聯幾張資料表來合成最終的展示資料，如：

select * from tagjoin tag_post on tag_post.tag_id=tag.idjoin post on tag_post.post_id=post.idwhere tag.tag='mysql';

同樣的，我們可以用以下查詢來代替：

select * from tag where tag='mysql';select * from tag_post where tag_id=1234;select * from post where id in(123,456,567,9989,8909);

看似後者查詢步驟更多了，原本一個方法查詢就能出結果，現在直接變成三個。但是這樣做的好處是：

1、單表查詢更利於後續的維護。

在實際開發場景中，在程式碼初步開發階段（如果攤上一個不太靠譜的產品），業務發生變動，某張表的結構發生變動，很可能整個join查詢都變得不可用，複雜的關聯查詢，在修改時，基本等於推倒重來。

但是如果我們使用了單表查詢，拆成上述例子中的三個步驟，我們可能只需要修改其中的一個步驟即可，比較利於維護。

2、程式碼可複用性高

這個不用多說，join聯表的SQL，基本不太可能被複用，但是拆分後的單表查詢，比如上面例子中，我查詢出tab資料，任何地方組裝需要tab資料，我都不需要再次做相關查詢，直接使用。

3、效率問題

join聯表查詢，小表驅動大表，透過索引欄位進行關聯。如果表記錄比較少的話，效率還是OK的，有時效率超過單表查詢。但是如果資料量上去，多表查詢是笛卡爾乘積方式，需要檢索的資料是幾何倍上升的。另外多表查詢索引設計上也考驗開發者的功底，索引設計不合理，大資料量下的多表查詢，很可能把資料庫拖垮。

相比而言，拆分成單表查詢+程式碼上組裝，業務邏輯更清晰，最佳化更方便，單個表的索引設計上也更簡單。用多幾行程式碼，多幾次資料庫查詢換取這些優點，還是很值得的。

4、減少冗餘欄位的查詢

在很多業務中，我們可能對某條記錄只需要查詢一次，此時如何使用關聯查詢，則不可避免的需要重複地訪問一部分資料，從而可能會加劇網路和記憶體的消耗。

5、快取利用率更高

比如上面查詢中的tag是不常變動的資料，快取下來，每次查詢就可以跳過第一條查詢語句。而關聯查詢，任何一張表的資料變動都會引起快取結果的失效，快取利用率不會很高。

6、其他

資料庫資源比較寶貴，很多系統的瓶頸就在資料庫上，很多複雜的邏輯我們在Service做，不在資料庫處理會更好。

在後續資料量上去，需要分庫分表時，Join查詢更不利於分庫分表，目前MySQL的分散式中介軟體，跨庫join表現不良。

單表查詢+程式碼上組裝相當於解耦，現在開發中，我們常常使用各種ORM框架，不知道你的聯查orm給你搞成了什麼樣,你是很難直接最佳化。

以上理由，強烈推薦在今後的開發中，儘可能的使用單表查詢+程式碼上組裝的方式。使用Stream lambda + mybatis plus + lombok， 酸爽！

單表 VS 聯表

基本就這些了，你的看法呢？