最近萬年議題又被拿出來討論了,「該把程式碼寫在 Stored Procedure,還是寫在 Application 裡面?」
⠀
以下是個人的看法以及選擇,僅供參考。
⠀
我個人的背景是這樣的,都是以開發 Web 應用程式為主,資料庫的使用經驗都在 SQL Server,其他的資料庫領域我不了解,在這樣的背景之下我個人傾向不使用 Stored Procedure 的,原因如下:
⠀
1. 對 DB 的操作已經是在應用程式生命週期的末端,這時候關注的應該是「效能」,如何運用最少的資源(CPU、Memory、Network IO、Disk IO、Money...)最快的速度拿到想要取得的資料,如果把程式碼都寫在 Stored Procedure,為了效能這件事,就會開始在商業邏輯中混入一些 Temp Table、額外定義 Table Type、因效能而使用的特殊語法...等,隨著時間流逝這個 Stored Procedure 就慢慢變成了哥吉拉。
⠀
2. 由於 SQL Server 的改進,Stored Procedure precompiled 的優點早已消失。
(https://www.codeproject.com/Articles/414272/Stored-Procedures-DO-NOT-increase-performance)
⠀
3. 被 Parameter Sniffing 搞得很煩。
⠀
4. 身為那條龍,我為何要將原始碼放在兩個地方?
⠀
雖然我不想使用 Stored Procedure 但不表示可以忽視查詢效能這件事,基本對 Index 的了解、各種 JOIN 差異、查詢計劃的解讀、...等,會影響查詢效能的要略懂,也順便跟還在跟哥吉拉奮戰的朋友說聲辛苦了。
sql index查詢 在 91 敏捷開發之路 Facebook 的最佳解答
Entity Framework Performance and What You Can Do About It
傳送門:https://www.simple-talk.com/…/entity-framework-performance…/
很多時候 ORM 慢,不是本身慢,而是使用 ORM 的人犯了幾個不該犯的錯誤,下列列出該注意的事項:
① model還沒給條件,就觸發執行 SQL 的問題
② "N+1" Select 的問題(沒有一次把要用到的關聯資料撈出來)
③ Select * 欄位全撈的問題
④ DataType 不相符的問題
⑤ Miss Index 的問題
⑥ 如何讓查詢計畫 reuse 的問題,例如分頁查詢影響查詢參數的方式
⑦ 批次作業使用 BulkInsert 相關的 API 可以提升 10 倍以上的效能
⑧ 用 AddRange() 取代迴圈裡面的 Add(),搭配AutoDetectChangesEnabled 開關。
※ 範例的效能提升:reduced from 34 seconds down to 85 ms – a 400x speed boost!
⑨ 如果只是要讀資料,沒有要異動,透過 AsNoTracking 關掉 Change tracking。
其他的注意事項,請自行參考文章後半部細節。
#EntityFramework #程式不是會動就好
sql index查詢 在 SQL SERVER 建立索引 - YouTube 的必吃
職訓中心107-2程式設計師講解老師:許志強老師. ... <看更多>
sql index查詢 在 經驗分享:建立INDEX後,讓SELECT效能變慢 的必吃
請問:Azure SqlDataBase(Paas)可以透過異動複寫的方式將異動資料,抄寫到地端的SQL Server資料庫嗎? 我查詢參考Microsoft網站的相關文章,大部分都是地端SQL Server ... ... <看更多>