251026056128
先表明立場，任何時候都不要在後臺代碼裡拼接sql。(除了中小公司內部報表類需求外)
首先，提主遇到的大公司拼接sql，“都”明顯是偽命題。在互聯網公司的應用領域內，是嚴禁嵌套，拼接sql的。一個大流量超高併發的系統，數據庫鏈接池資源，是非常寶貴的。基本決定了系統的性能上限。不然為什麼加分佈式緩存，數據庫分庫分表呢？對於高頻低熵的系統，明顯高頻次低耗時的數據庫鏈接是最可靠的方式。
其次，對於各種大型的傳統IT服務業和政府，銀行類系統，由於系統本身相對於一線互聯網公司，併發非常低。所以線程對數據庫鏈接的持有時間可以稍微耗時長一些，以得到比較快的系統響應。其實這麼做，也並非是明智之舉。明顯，互聯網類的技術拆分和技術架構，對於大公司的各種場景更為合適。傳統的IT那種所有難題扔sql，扔給存儲過程的方式已經過時多年。
最後，對於高併發的大型在線系統，有複雜查詢類的需求，絕不推薦在後臺sql中用複雜的查詢去實現。這個對於系統的成本消耗明顯太高。對於複雜的查詢，自然有其他的技術架構去實現。
可以多多關注一線互聯網公司的架構技術，也可以看下我之前的回答。
發現持續還有人關注本問題，看到大家來自各個不同業務領域，再聊一些吧。
本身這個問題是高併發類系統的常識性問題。不管是低頻高熵的傳統業務，還是高頻低熵的互聯網業務公司，技術架構往往是業務特性來決定的。
傳統IT公司，IT服務類公司確實仍然存在拼接這樣粗暴的實現方式。因為併發低，迭代快。當然如果能滿足低頻低熵的業務需求，也無可厚非。但單單從技術角度看，這麼做可能並不是最優。事實上，傳統公司的新項目也很少有人會這麼玩了。(節省幾臺服務器，也是錢啊)。
很多同學領域不同，對業務需要的技術理解自然會有區別。技術同學可以適當多看機會，多接觸不同業務領域的技術實現方案。多思考技術架構這樣設計背後的業務原因。
另外，如果有任何問題或質疑，歡迎去看我之前的回答，或留言與我討論。不喜勿噴。
AI君
曾帶過一個項目，其中一個數據接口處理，orm需要14個小時，動不動over heap. 10多年沒碰代碼的我，被迫上線現場改用純sql,放數據庫處理，處理時間2分鐘以內。
廈門點拍攝影
題主說的確實存在，但是要區分不同業務類型和領域的“大”公司，軟件行業裡面，有bat這樣的互聯網公司，也有神州這樣的看起來大的公司，也有藍凌這樣的專做OA的大公司，還有思迅這樣在收銀軟件獨霸一方的。他們在各自領域，都是大公司。
如果是傳統管理軟件的公司，這種情況確實大量存在。這和歷史原因，業務現狀有關。他們的主要問題是每天面臨大量不同項目的不同功能需求要完成，當合理的使用拼接sql方式，能夠加快開發交付速度，也能靈活面對業務需求的變化。這類軟件的業務複雜度遠大於併發需求，所以這樣也能抗住性能壓力，也能完成各種複雜功能（業務複雜變態程度遠超一般長期接觸互聯網行業的工程師的想象）的快速開發。
而如果是一個互聯網公司，業務又是2C的，那麼就不會拼接sql了。往往採用基礎表的數據整條讀寫訪問（數據庫淪為持久化工具之一），數據內存做緩存，數據邏輯關係由代碼而不是sql完成，以提高效能，降低延遲，提高併發（按每秒單節點10w次記）。所以，這種大公司是絕不可能大量有sql拼接的，有也是少數sql，也或許是緩存穿透後的操作。
還有一種情況，就是大公司裡面某些團隊，接了開發任務，項目又是項目產品型的，項目負責人開始為了加快進度，搭建的基礎架構就偏簡單，加之業務還沒成熟，技術選擇上也會採用拼接sql來實現，這樣對開發人員要求低，開發速度快。
綜上所屬，就會出現，題主說的情況，那些說沒有的人，也沒錯，他們只是單一行業接觸的多，跨行業領域接觸的少而已。
路人甲21783239
我們不推薦字符串連接拼湊sql的做法？
1、拼湊的做法，尤其是sql較為複雜的時候，不便於閱讀。讓整個sql的邏輯更加混亂。哪部分是被查詢字段，哪部分是條件，哪部分分組排序等等，不夠清晰。
2、很多小白沒什麼經驗，不懂sql注入的手段和危害，沒有對用戶輸入參數進行有效性及合法性的驗證。拼湊sql會導致系統存在風險。
3、比如有特殊原因，需要修改業務表名，那麼拼裝sql幾乎能噁心死你，要修改的代碼太多了。但如果我們嚴格按照模型層封裝的結構去調用，就方便很多了。
拼湊sql不會有語法錯誤，但我們團隊明令禁止這種做法，每個團隊都有自己的規範。不想去評價別人的做法。
遠揚不愛甜食
1.數據庫更換時，部分數據庫拼接的語法有區別，而orm框架基本做了兼容可以很方便的切換數據庫。
2.互聯網系統流量內容查詢不能過於複雜，所以使用orm已經可以滿足大部分需求。但是內部業務複雜的系統時，orm因為為了滿足1，大量的共通拼接查詢寫法效率相對較低，很難做查詢優化。所以所有的orm框架在提供對象關係管理的同時，也都提供了sql語法的支持為了滿足特殊業務需求。java的mybatis比hibernate更有效率的原因就在這。python的django中的orm框架因為語言性能的原因，orm寫法和sql寫法對比效果更明顯。orm在簡單的curd上是很方便的，但是碰到複雜邏輯時，如果設計未考慮到複雜的鏈接，單純使用orm就是災難。
拽拽紳士76
看了回答。任何問題都不只是單純的技術問題。討論任何問題都應該有一個業務場景，所以造成了大家的爭論。
高併發場景下確實不建議複雜sql，查詢緩慢造成數據庫服務器的巨大壓力。
如果你的系統數據量沒那麼大，併發也沒多少。寫個複雜sql有有什麼問題呢？
有些公司採取的措施是一刀切，複雜sql不能有，嚴禁sql嵌套循環等。一刀切帶來的問題是可能不是一個問題，而為了解決所謂的問題浪費時間。我想說的是複雜sql效率不一定低，循環極少數次又有什麼問題呢？最終的目的不還是為了保證查詢效率嗎？他們之間沒有必然的關係。這種問題可以採用開發規範或者代碼審核來避免。開發規範可以警示開發人員:聯合查詢n張表的時候需考慮性能問題，並考慮是否拆分sql。
還是那句話，脫離了業務場景討論技術就是耍流氓。
首席代碼執行官
最終不都是拼接成sql字符串的麼？ 防止注入就自己把參數檢查做到位就好了。各種框架表面好用，等查問題的時候會噁心死你。
阿拉河南人
不拼接你想怎麼寫，那些框架組件不也是幫你實現拼接的。只不過不要直接把參數拼接進去，用參數綁定處理。
契約定論
不得了，現在用go寫，懶得用orm，拼的sql，咋辦？既不會被注入，也可以方便各種切庫，效率還比較高，怎麼破？
陳陳陳chenchen
拼接字符串，看你拼在哪裡。
