四個面向的資料庫效能建議

1. 給開發人員的
資料庫效能建議
RiCo
RD Leader

2. 大綱
• TSQL
• ORM
• INDEX
• DB Design
• Q & A

3. 效能調校三大層面
• 資料庫設計
多餘索引、缺少索引、過度正規化、不適當的資料型別、
不適當的資料長度、資料表分區、缺少資料歸檔策略、
不適當的檔案大小、頻繁變更Schema…
• 查詢設計
不良子查詢、不良Like/OR/Exists操作、不良資料量、
長時間交易、不當使用Cursor/Trigger/View….
• 應用程式設計
缺少快取、OLAP/OLTP未分離、SQL Server用於NoSQL、
資料庫之間高耦合(依賴中間層解耦合)，不是只有SQL Server….

4. 其他用途DB
用途 名稱
Graph SQL Server 2019(2017)
Key-Value Redis
MQ Kafka、RedisStream
Wide column Cassandra
Time Series InfluxDB
Documents MongoDB、Solr

6. TSQL
• 不只有商業需求，資料表大小、Join資料表數量、彙總操作
• 一致的資料型別(變數、參數和欄位)避免隱式轉換或低校執行計
畫，且少使用row by row操作(while loop和cursor一樣糟糕)
• 參數化，可預防SQL Injection且高併發下避免重新編譯(大量降
低CPU)
• 合理資料量擷取，可降低網路傳輸量、記憶體和硬碟資源競爭
• 保持交易處理時間越短越好並避免孤兒交易，正確控制commit
和rollback，可依需求使用樂觀交易取代
• 符合SARG格式，可避免索引無效導致使用掃描操作
• 非優先使用提示(Hint)，提示永遠都是最後手段

7. • 避免View之間的 join或巢狀View，大部分效能很差
• 小心SP的參數探測問題，因只使用一個執行計畫(*SQL Server
2022)
• 簡單、簡單、簡單(重要的事情要說三遍)，DB處理簡單CRUD，
商業邏輯處理不建議放DB，避免任何驚奇或夜哨

8. ORM
• 參數化和欄位資料型別，避免效能低落
• 更新、新增、刪除操作，我們大多可不用干涉，但複雜的查詢可改用
SP取代來提高查詢效能，查詢也可善用AsNoTracking
• SQL Server建議開啟optimize for ad hoc workloads，可避免只建立
完整計畫，並善用記憶體
• Async可提高app吞吐量和回應效能，Skip and Take實現後端分頁
• DbContext 預設生命週期為 Scoped，建議和 Http Request 同生共
死，確保資料一致性和可用性
• 使用快取降低SQL Server負擔
• 服務註冊使用 AddDbContextPool
(預設1024)，減少 Instance 初始化成本

9. INDEX
• 選擇正確叢集索引，適用於查詢中含有Group by、Order By、
Between或範圍條件
• 叢集索引越窄越好(越少鍵值數量和長度小)，表示非叢集索引使
用較少儲存空間
• 涵蓋索引設計正確，可降低死結發生頻率、避免資料表掃描操作、
算一種常見改善效能方法
• 非叢集索引鍵值越窄越好(越少鍵值數量和長度小)，可讓索引更
有效率且管理成本越低
• 查詢操作含有Where、Join、Top、Order By、Group By，當遇
到效能問題，建議設計正確索引

10. • 如果可以的話，優先考慮唯一索引，大部分比非叢集索引有更好
效能
• 確保索引第一個索引鍵值有高選擇性
• B-tree索引高(深)度越低越好
• 一個資料表索引過多過少都不好，查詢和更新效能要取得平衡
• 保證透過該索引查詢效益遠大於DML成本
• 在一個很小資料範圍欄位建立索引效益很低
• 個人建議讓SQL Server自動維護索引統計資料
• 個人建議OLTP系統都優先使用窄索引

11. DB Design
• 依照商業需求，進行資料封存作業(冷、熱和歷史資料)
• 不同資料庫的資料同步，避免直接進行同步，建議透過中間層服
務
• 低商業價值資料或OLTP和OLAP可拆開至不同Server和SQL
Instance，讓資源使用最大化
• 切割資料檔案數量並設定合適大小和成長大小
• 優化tempdb(SQL20016後無需啟用TF1117、1118)
• 主要滿足商業需求並降低維護成本(資料正確為前提) 、次要高可
用性和高彈性水平擴充、最後滿足系統所需效能

12. Q & A

13. 工商服務
RiCo技術學院

14. Thank You