DP-300 Azure 資料庫管理員 - 第四天課程筆記

第四天講完才懂，性能問題根本不是 DBA 的責任啦，是開發者的鍋。但偏偏所有人都先來找我們。

性能監控的真相

某個客戶 CPU 爆到 90-100%，業務部門說「快加硬體啦」。結果加了新 CPU 以後，還是一樣爆。講師跑過去一看，才發現應用層有個死循環 Bug，天啊。所以第一個功課就是別盲目加硬體，先找出瓶頸在哪。

性能基準線要分兩個角度看：終端使用者看頁面載入 3-5 秒是否夠快，資料庫後端看 CPU 使用率、緩衝區命中率（要 >95%）、磁碟佇列長度、TPS。記憶體這塊要特別注意，SQL Server 會像貪吃蛇一樣把所有記憶體吃光，必須手動設定 Max Server Memory。但這也給了我們省錢的角度，緩衝區命中率達到 95% 就代表記憶體夠了，說不定可以降規格。

找問題的工具

Extended Events 徹底取代了舊版 SQL Profiler，輕量、內建在引擎，雲端也支援。關鍵場景是 CPU/記憶體/磁碟看起來都很正常，但查詢就是慢，那就可能躲著鎖或阻塞。平常千萬別開著它，會整天記錄資料，遇到問題才啟動找原因。

執行計畫從右到左讀，越貴的運算子在前面，往往就是那個地方爆了。DMV 也很好用，sys.dm_* 可以查連線數、來源 IP，找到誰在打爆伺服器。

儲存和磁碟配置

本地環境生產必用 RAID 10，別碰 RAID 5（這是判斷 DBA 專不專業的指標啦）。雲端底層已經三副本了，其實做軟體 Striping（RAID 0）就夠，磁碟最多 8 個。TempDB 要放在最快的磁碟，因為它 I/O 最兇悍。

選存儲類型也有眉角：Managed Disk 給資料檔案（高 IOPS）、Blob Storage 給備份（高吞吐量）、File Storage 給叢集仲裁。

SARGability：不要害自己

WHERE 左側放函數就完蛋了。YEAR(OrderDate) = 2026 是 Non-SARGable，改成 OrderDate >= '2026-01-01' AND OrderDate < '2027-01-01' 才行。前置 % 的 LIKE 也一樣，'%keyword' 不行，搜尋引擎沒辦法用索引。

真香的地方是，結果正確不代表性能沒問題。SQL 會幫你算對答案，但慢到爆。這點踩坑過才懂。

-- Non-SARGable (炸了)
SELECT * FROM Orders WHERE YEAR(OrderDate) = 2026;

-- SARGable (真香)
SELECT * FROM Orders 
WHERE OrderDate >= '2026-01-01' AND OrderDate < '2027-01-01';