長sql語句 和 屢次sql查詢結果進行整合，哪一種效果比較好

• 問題

最近爲了實現一個功能，僅僅sql語句寫了一百多行，最後功能實現了，可是總感受有一點點愚蠢。由於在每次添加或編輯一個小的功能時，本身很容易就被複雜sql語句給看蒙了，實在太長了，一個括號又一個括號。

這時候我就在想，可不能夠將查詢結果分屢次查詢，再將查詢結果進行整合，最後返回相同的結果。

1. 首先咱們應考慮的時咱們所作的業務是否對數據的一致性要求很高，對於財務、網上商城的庫存之類的問題，這種狀況就須要一條sql搞定；若是分屢次查詢，當第一次sql執行完畢後，第二次查詢的數據又變了，這種狀況是不適合拆分sql的。
2. 而後就是考慮功能的實現查分紅多條sql是否效率會有提升

無非就是一個sql語句減小了java代碼操做的時間，直接返回了須要的數據

多個sql會增長java的代碼量，下降java的執行效率（目前個人理解是java效率會比較高，比sql效率相比微乎其微）（好維護，查詢效率高）

• 網上答案及我的理解

1：一個一個查出來整合會效率更高
2：分次查詢，有利於數據庫自動使用到索引，會提升查詢效率（極大減小查詢時間）
3：通常單表查詢，對於業務系統和 orm 框架來講，不少是有緩存的，其實查的是緩存，效率更高，而多表聯合查詢，通常會禁用這個級別的緩存（利用緩存，減小查詢時間）
4：聯合查詢的sql語句，大多數在查詢語法過程當中，總數據處理量會變成多表的乘積。總處理數據量是 n*m*...，那麼根本就快不起來。而單表查幾條，參與運算的數據量就是主數據加幾條關聯數據。（多表查詢複雜度指數型增加）

 

大sql其實比小sql實現起來要麻煩得多，中間夾了太多業務，不只麻煩也易出錯，維護的人也不方便（本人在寫這個複雜sql的時候常常想半天，更況且別人要看這個sql的人，應該更是一臉懵逼吧）。相對來講小sql，用本身熟悉的語言如java去實現業務邏輯，比較清晰明瞭。並且使用小sql查詢，也許在緩存中就有都不用去查詢數據庫。

我原本想的是分紅多個sql查詢，後來想屢次查詢數據庫會下降效率，因此選擇了較長的sql實現功能，後來網友告訴我：

1.有鏈接池複用，不會有太多明顯的屢次鏈接開銷；
2.背慢鍋的通常都是JOIN；
3.其實在ORM框架來看，JOIN產生了中間結果，不是A也不是B而是AB混合體，所以緩存怎麼搞（不用緩存了）因此問題3仍是各查個的吧而後在應用裏面進行數據處理。
4.有緩存就是吊，不服數據庫你本身坐啊

一次查詢：缺點是若是兩個表數據多，則中間結果集太大，須要較多的內存資源，以時間換空間。

屢次查詢的優缺點和一次查詢正好反過來。

屢次查詢也能夠在程序中對每一次查詢的中間結果作處理，這是一個靈活性。

一次查詢若是數據量大的話，屢次查詢要快一些，至關因而用空間換時間。

• 總結：

分開寫屢次拼裝較好，sql寫的太長的話，後期若是須要維護或者業務有新的需求會比較麻煩（長遠思考：方便維護，和添加新的功能），建議是單一化，便於維護，便於之後別人理解業務（容易閱讀）。業務實現最好是簡單明瞭化，這樣出錯的概率小（正確率提升）。