來源：知乎
連結：https://www.zhihu.com/question/68258877/answer/2071090987
一直想要聊一聊關于開發中更建議使用單表查詢+代碼層組裝 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（Object Relational Mapping）架構采用中繼資料來描述對象與關系映射的細節，中繼資料一般采用XML格式，并且存放在專門的對象一映射檔案中。簡單了解為一種架構的格式），不知道你的聯查orm給你搞成了什麼樣,你是很難直接優化。以上理由，強烈推薦在今後的開發中，盡可能的使用單表查詢+代碼上組裝的方式。
使用Stream lambda + mybatis plus + lombok， 酸爽！
單表 VS 聯表
