核心觀點：視複雜度與性能要求而定，但原則上「能不寫就不寫」
✅ 適合下推到 SQL 的場景
- 集合運算、過濾、聚合、連接：
WHERE, GROUP BY, JOIN, WINDOW FUNCTIONS 是資料庫強項，網絡傳輸量少，優化器能用索引/統計信息。
- 數據完約束：
CHECK, FOREIGN KEY, TRIGGER（慎用）保證數據一致性，比應用層可靠。
- 批量數據變更：
UPDATE ... SET col = CASE WHEN ...、MERGE（Upsert）單條語句完成百萬行更新，避免應用層循環 RPC。
- 報表/分析查詢：複雜 OLAP 查詢直接在數據庫完成，利用列存、並行查詢、物化視圖。
❌ 應避免在 SQL 寫的邏輯
- 複雜業務規則、狀態機、流程編排：
IF/ELSE 嵌套、游標循環、動態 SQL 拼接 → 難測試、難版本控制、難重構、鎖表風險高。
- 外部系統調用、文件操作、加密/解密：數據庫不是應用服務器，擴展性差，阻塞工作線程。
- 大量字符串處理、正則、JSON/XML 解析：資料庫函數表達力弱，性能差，應在應用層用成熟庫處理。
- 跨庫/跨Schema 分布式事務協調：應用層用 Saga、TCC、Seata 等模式管理。
架構分層視角
| 層次 | 職責 | 典型技術 |
|---|
| 數據訪問層 (DAL/Repository) | CRUD、參數化查詢、映射 | MyBatis, JPA, Entity Framework, Dapper |
| 領域/業務邏輯層 (Service/Domain) | 業務規則、事務邊界、領域事件 | Java Spring Service, .NET Core Service, Go Service |
| 表現層 (Controller/API) | 請求驗證、序列化、協議適配 | REST, GraphQL, gRPC |
將業務邏輯下沉到 SQL = 破壞分層架構，導致：
- 邏輯分散在 Java/C# 和 Stored Procedure 兩處，認知負荷雙倍。
- 存儲過程無法單元測試（無 Mock、無 CI/CD 流水線支持）。
- 數據庫成為單點擴展瓶頸（CPU/內存難水平擴展），而應用層無狀態易擴展。
- 綁定特定數據庫方言（Oracle PL/SQL vs T-SQL vs PL/pgSQL），遷移成本極高。
性能視角的反直覺真相
- 網絡往返 (RTT) 才是高併發下的殺手：應用層發 10 條簡單 SQL 遠比 1 條複雜存儲過程慢，但 批量操作、管道化、PreparedStatement 可將 RTT 擴攤至微秒級。
- 優化器不一定比人聰明：複雜存儲過程的執行計劃可能因參數嗅探、統計信息過期而災難性失效，調優極難。
- 應用層緩存（Redis、本地緩存）比 SQL 優化收益大得多。
決策清單：該不該寫進 SQL？
- 是否為**純數據集運算**（過濾/聚合/連接/窗口）？→ 是 → SQL。
- 是否涉及**業務規則、流程控制、外部依賴**？→ 是 → 應用層。
- 是否為**高頻熱點路徑**且經證實應用層網絡開銷為瓶頸？→ 考慮 SQL 下推，但需嚴格代碼評審、測試、監控。
- 團隊是否具備**數據庫開發/運維能力**（執行計劃分析、索引設計、鎖分析）？→ 否 → 堅決不寫複雜邏輯。
總結
SQL 專注「數據怎麼存、怎麼查、怎麼約束」；應用層專注「業務怎麼跑、流程怎麼轉、規則怎麼驗」。除非有極強性能證據且團隊具備深厚 DBA 功力，否則**業務邏輯留在應用層**，用成熟的 ORM/Query Builder 發參數化 SQL，才是長期可維護、可擴展、可測試的架構選擇。
