可以考慮從以下幾個方面看

1、查詢時間，

如果兩次查詢得到資料的時間很快，而合起來很慢，那麼選擇兩次

2、返回結果集

如果兩次查詢得到的結果集都很大，二次加工需要很多開銷；而合起來一次查詢的結果集相對較小，考慮合起來

3、資料庫效能/伺服器效能

如果資料庫記憶體小，效能吃緊，少一點邏輯計算會好一些

如果資料庫和伺服器之間的網路通訊是瓶頸，那麼減少通訊資料量優先考慮

如果伺服器效能吃緊，儘量減少伺服器的開銷

4、如果上述都不是問題

建議考慮以後接手的人能否看懂你的sql邏輯

個人經驗

有一段時間很反感透過程式碼加工資料，傾向於一個sql吃遍天（透過sql完成邏輯計算，直接得到結果），sql寫的越來越複雜

隨之而來遇到2個問題

1、查詢效能往往很差，缺少資料庫索引等等的方案最佳化

2、除了自己沒人看得懂；幾個月後自己也看不懂睡

再後來明白了balance ，儘量有閒的資源來運作，追求的是最終結果

即便非要透過資料庫來實現，也會分步走，透過臨時表，儲存過程等等來做

大道至簡