Azure 建立 SQL Database Server 與 create database 如何計價?

2026-03-182026-03-18

在 Azure SQL 的世界裡，「伺服器 (Logical Server)」與「資料庫 (Database)」的計價邏輯是分開的。簡單來說，建立「伺服器」本身是免費的，真正的費用產生在「資料庫」的資源配置上。

以下是詳細的計價架構說明：

1. SQL Database Server (伺服器層級) —— 免費

當你在 Azure 入口網站建立一個 SQL Server 時，這只是一個「邏輯容器」，用來管理防火牆、身分驗證和安全性原則。

費用：$0。
注意：即便你建立了一百個伺服器，只要裡面沒有資料庫，Azure 就不會收費。

2. Create Database (資料庫層級) —— 收費主體

一旦你在伺服器下建立資料庫，計價就開始了。主要分為兩種模式：

A. DTU 模式 (適合預算固定、簡單需求)

這是一種將 CPU、記憶體、I/O 綑綁在一起的單位。

Basic (基本)：約 $5 USD/月。適合極小型的開發測試。
Standard (標準)：約 $15 ~ $4,400+ USD/月。適合大多數正式生產環境。
Premium (進階)：費用較高，適合需要極高 I/O 效能的企業。

優點：價格固定好預測，包含了一定額度的儲存空間。

B. vCore 模式 (適合需要精確控制資源)

將運算 (Compute) 與儲存 (Storage) 分開計價，最符合地端 SQL Server 的概念。

佈建模式 (Provisioned)：你預先決定要多少核 CPU (例如 2 vCores)，不論有無使用，每小時固定收費。
無伺服器模式 (Serverless)：按「秒」計費。
- 優點：沒人用時可以自動暫停（Auto-pause），暫停期間只收儲存費，不收運算費。
- 適合：流量不穩定的應用程式。

硬體組態

在基於 DTU 的採購模式中，客戶無法選擇用於資料庫的硬體配置。雖然指定的資料庫通常會在特定類型的硬體上停留很長的一段時間 (通常為數月)，但某些事件可能會導致資料庫移至不同的硬體。

例如，當資料庫擴增或縮減至不同的服務目標，或是資料中心內目前的基礎結構已接近其容量限制，或是目前使用的硬體因達到使用壽命而退役時，可以將資料庫移至不同的硬體。

如果將資料庫移至不同的硬體，工作負載效能可能會改變。 DTU 模型保證在資料庫移至不同的硬體類型時，只要其服務目標 (DTU 數目) 維持不變，DTU 基準工作負載的輸送量和回應時間大致上會是相同的。

不過，在 Azure SQL Database 中執行的各種客戶工作負載中，對於相同服務目標使用不同硬體的影響可能更加明顯。不同的工作負載可能會受益於不同的硬體設定和功能。因此，針對 DTU 基準以外的工作負載，如果資料庫從一種類型的硬體移至另一種，就可能會看到效能差異。

客戶可以使用虛擬核心模型，在資料庫建立和調整期間選擇其偏好的硬體設定。在虛擬核心模型中，會針對單一資料庫和彈性集區記錄每個硬體設定中每個服務目標的詳細資源限制。如需詳細資訊，請參閱硬體設定。

3. 除了資料庫，還有哪些隱藏費用？

當你建立資料庫後，帳單通常會包含以下項目：

運算費 (Compute)：CPU 與記憶體的消耗。
儲存費 (Storage)：資料實際佔用的硬碟空間。
備份儲存 (Backup Storage)：
- Azure 提供免費的預設備份空間（通常等於你的資料庫大小）。
- 超過的部分或長期保留（LTR）會額外收費。
網路流量 (Data Transfer)：
- 資料「流入」Azure 免費。
- 資料「流出」Azure (例如傳回你的辦公室或跨區域) 會收費。

總結建議

需求場景	推薦模式	預估起步價
學生/個人練習	DTU – Basic	~$5 USD / 月
小型網站/開發	vCore – Serverless	視使用量 (不使用時僅儲存費)
中大型穩定生產	vCore – Provisioned	視核心數 (約 $100+ USD 起)

試算「無伺服器」模式的省錢方案

「無伺服器 (Serverless)」模式是 Azure SQL 最具彈性的省錢方案，特別適合 「只有上班時間在使用」 或 「偶爾才有大量任務」 的開發與測試環境。

它的核心邏輯是：有用到才算錢（按秒計費），沒人用時自動休眠（只收硬碟費）。

1. 無伺服器模式的計價公式

你的帳單會由兩部分組成：

計算費用 (Compute)：以「vCore-秒」計費。當資料庫在運行時，根據實際使用的 CPU 核心數收費。
儲存費用 (Storage)：以「GB/月」計費。不論資料庫是否在跑，只要資料還在硬碟裡，這部分就會收費。

省錢關鍵：自動暫停 (Auto-pause)

你可以設定「閒置多久後自動暫停」（最低可設為 1 小時）。暫停期間，計算費用 = $0。

2. 情境試算：開發用的小型資料庫

假設你有一個 50GB 的資料庫，設定規格為：最少 0.5 vCore / 最大 2 vCores。

A. 傳統「定額佈建 (Provisioned)」模式

不論有無使用，24 小時都在跑。
費用估計：約 $75 ~ $150 USD / 月 (視核心數而定)。

B. 「無伺服器 (Serverless)」模式 (省錢方案)

假設這是一個開發環境，只有工程師上班會用到：

運作時間：週一至週五，每天 10 小時（包含 1 小時冷卻期），其餘時間自動暫停。
使用量：平均使用 0.5 vCore。
儲存量：50 GB。

試算明細 (以 2026 參考預估價計算)：

計算費：$0.000145 \times 0.5 \text{ (vCore)} \times 36,000 \text{ (秒/10hr)} \times 22 \text{ (天)} \approx \mathbf{\$57.42 \text{ USD}}$
儲存費：$50 \text{ GB} \times \$0.115 \approx \mathbf{\$5.75 \text{ USD}}$
總計：約 $63.17 USD / 月

結論：比起 24 小時不間斷的固定規格，Serverless 幫你省下了 50% 以上 的費用。

3. Serverless 的「陷阱」與對策

雖然 Serverless 看起來很省，但要注意以下兩點：

陷阱	對策
起床氣 (Latency)	暫停後的第一個連線需要「喚醒」資料庫，通常會有 30~60 秒的延遲。如果你的 App 無法忍受這點，請關閉自動暫停。
長時間高負載	如果你的資料庫 24 小時都有人在用，Serverless 的單價比 Provisioned 貴。建議 24 小時運行的系統改用「預留容量 (Reserved Capacity)」更省錢。

如何開始設定？

在 Azure 入口網站，將資料庫的 「計算層 (Compute tier)」 改為 Serverless。
勾選 「啟用自動暫停 (Enable auto-pause)」。
將 「自動暫停延遲」 設為 1 小時。

如何從 Azure Monitor 查看目前的實際 vCore 使用量

要精確評估「無伺服器 (Serverless)」模式能幫你省下多少錢，觀察 CPU 使用率 (CPU percentage) 與 vCore 分配量 (vCore allocated) 是最關鍵的步驟。

你可以透過 Azure 入口網站內的 Azure Monitor 工具，依照以下步驟查看：

1. 進入計量 (Metrics) 介面

登入 Azure Portal。
導覽至你的 SQL Database 頁面。
在左側選單的「監控 (Monitoring)」區塊中，點選 「計量 (Metrics)」。

2. 設定監控指標

在計量圖表中，你需要加入以下兩個關鍵指標來對照：

指標 1：CPU 百分比 (CPU percentage)
- 這代表你的資料庫實際上「用掉了多少比例的運算力」。
- 如果這個數值長年低於 10%，表示你目前的規格可能買太大了。
指標 2：App CPU 已計費 (App CPU billed) —— 僅限 Serverless 模式
- 這會直接顯示 Azure 實際上向你收取的 vCore 數量。
- 你會看到它隨著流量上下波動，並在自動暫停期間歸零。

3. 分析數據以決定省錢策略

觀察圖表時，請注意以下幾點：

觀察結果	隱含意義	省錢建議
圖表有大段空白	資料庫已進入「自動暫停」。	恭喜！你已經在享受 Serverless 的最大節費效果。
CPU 始終維持在 1%~5%	資料庫一直醒著，但幾乎沒在做事。	檢查是否有背景程式（如監控軟體）定時連線，導致資料庫無法休眠。
CPU 經常衝到 90% 以上	現有的 vCore 上限可能太低。	考慮調高 Serverless 的「最大 vCore」，避免效能瓶頸。

4. 進階：使用 SQL 查詢查看

如果你不想看圖表，想直接用 SQL 指令抓取過去幾小時的實際消耗，可以在 Query Editor 執行這段指令：

SQL

SELECT end_time, 
       avg_cpu_percent, 
       avg_instance_cpu_percent, 
       avg_memory_usage_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

這會顯示過去一小時內，每 15 秒一次的資源消耗記錄。

接下來的省錢動作

如果你發現 CPU 使用量極低且不規律，我建議你：

確認 「自動暫停延遲 (Auto-pause delay)」 是否設得太長（預設有時是 1 小時，可以視情況縮短）。
檢查是否有 「預設任務」（例如：深夜的索引重建）會把資料庫吵醒，導致它無法在離峰時間暫停。

Max的程式語言筆記