前言
一直想要聊一聊關於開發中更建議使用單表查詢+代碼層組裝 or 聯表查詢 的問題，在開發中每個同學的開發中有各自的習慣，筆者在公司也和一些同事關於這方面有一些探討。
關於本文，更像是一些個人的看法，想到什麼說什麼，一定有不同的意見，歡迎大家留言，一起討論。
對比
在實際開發中，我們不可避免的要關聯幾張數據表來合成最終的展示數據，如：
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 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 聯表
基本就這些了，你的看法呢？