先表明立場，任何時候都不要在后臺代碼里拼接sql。(除了中小公司內部報表類需求外)

首先，提主遇到的大公司拼接sql，“都”明顯是偽命題。在互聯(lián)網公司的應用領域內，是嚴禁嵌套，拼接sql的。一個大流量超高并發(fā)的系統(tǒng)，數(shù)據(jù)庫鏈接池資源，是非常寶貴的。基本決定了系統(tǒng)的性能上限。不然為什么加分布式緩存，數(shù)據(jù)庫分庫分表呢？對于高頻低熵的系統(tǒng)，明顯高頻次低耗時的數(shù)據(jù)庫鏈接是最可靠的方式。

其次，對于各種大型的傳統(tǒng)IT服務業(yè)和政府，銀行類系統(tǒng)，由于系統(tǒng)本身相對于一線互聯(lián)網公司，并發(fā)非常低。所以線程對數(shù)據(jù)庫鏈接的持有時間可以稍微耗時長一些，以得到比較快的系統(tǒng)響應。其實這么做，也并非是明智之舉。明顯，互聯(lián)網類的技術拆分和技術架構，對于大公司的各種場景更為合適。傳統(tǒng)的IT那種所有難題扔sql，扔給存儲過程的方式已經過時多年。

最后，對于高并發(fā)的大型在線系統(tǒng)，有復雜查詢類的需求，絕不推薦在后臺sql中用復雜的查詢去實現(xiàn)。這個對于系統(tǒng)的成本消耗明顯太高。對于復雜的查詢，自然有其他的技術架構去實現(xiàn)。

可以多多關注一線互聯(lián)網公司的架構技術，也可以看下我之前的回答。

發(fā)現(xiàn)持續(xù)還有人關注本問題，看到大家來自各個不同業(yè)務領域，再聊一些吧。

本身這個問題是高并發(fā)類系統(tǒng)的常識性問題。不管是低頻高熵的傳統(tǒng)業(yè)務，還是高頻低熵的互聯(lián)網業(yè)務公司，技術架構往往是業(yè)務特性來決定的。

傳統(tǒng)IT公司，IT服務類公司確實仍然存在拼接這樣粗暴的實現(xiàn)方式。因為并發(fā)低，迭代快。當然如果能滿足低頻低熵的業(yè)務需求，也無可厚非。但單單從技術角度看，這么做可能并不是最優(yōu)。事實上，傳統(tǒng)公司的新項目也很少有人會這么玩了。(節(jié)省幾臺服務器，也是錢啊)。

很多同學領域不同，對業(yè)務需要的技術理解自然會有區(qū)別。技術同學可以適當多看機會，多接觸不同業(yè)務領域的技術實現(xiàn)方案。多思考技術架構這樣設計背后的業(yè)務原因。

另外，如果有任何問題或質疑，歡迎去看我之前的回答，或留言與我討論。不喜勿噴。