當外界把 SQL Server 2025 的焦點聚集在 AI 時，引擎其實同時在三個面向收割豐厚成果：安全性（Security）、效能（Performance）、可用性（Availability）。這些功能多源自 SQL Server 2022 的回饋與 Azure 雲端版本的長期實戰，最後在 SQL Server 2025 一次落地。

本章極長，可依興趣跳到對應段落：「安全性」、「效能」、「可用性」、「隱藏寶石」。所有範例只需 Developer Edition 即可在筆電上執行。

安全性#

Microsoft Entra 與 Managed Identity#

第 6 章已介紹 Microsoft Entra 與 Managed Identity 的基礎。本章補充幾個情境：

BACKUP / RESTORE TO URL with Managed Identity#

過去把資料庫備份到 Azure Blob Storage，需要 access key 或 SAS token。現在可改用 system-assigned Managed Identity：

1. 把 Azure Arc 的 system-assigned Managed Identity 授權到 Storage Account
2. 在 SQL Server 建立對應這個 Managed Identity 的 credential
3. 直接執行 BACKUP TO URL 或 RESTORE FROM URL

詳情：https://learn.microsoft.com/sql/sql-server/azure-arc/backup-to-url

Azure Key Vault 的 Managed Identity 支援#

TDE 等加密功能的金鑰可由 SQL Server 自管，或自 SQL Server 2016 起改放 Azure Key Vault（透過 EKM, Extensible Key Management）。EKM 過去要在 Microsoft Entra 建 service principal 與 client secret——又是「另一個密碼」。

SQL Server 2025 把 system-assigned Managed Identity 授權到 Azure Key Vault 即可建立 EKM credential，徹底走向 passwordless。

https://learn.microsoft.com/sql/sql-server/azure-arc/managed-identity-extensible-key-management

Microsoft Entra 服務主體 Login（用 OBJECT_ID）#

由於 Entra 中 application 的 display name 可能不唯一，SQL Server 2025 擴充 CREATE LOGIN 語法：

CREATE LOGIN [my_app] FROM EXTERNAL PROVIDER WITH OBJECT_ID = '...';

Security Cache 改進#

SQL Server 用 TokenAndPermUserStore 快取安全性 metadata。某些 master 層的安全管理操作會 invalidate 整個 cache，影響所有 login。

SQL Server 2025 對於 CREATE / ALTER / DROP login 與單一 login 權限變更，僅 invalidate 該 login 的 cache（Group login 仍維持 server 層 invalidation）。

https://learn.microsoft.com/sql/relational-databases/security/security-cache#known-issues

此改進不會解決 TokenAndPermUserStore 過大造成的效能問題（特別是大記憶體系統）；那需另外處理。

加密與密碼強化#

TLS 1.3 / TDS 8.0#

SQL Server 2022 引入 TDS 8.0（先 TLS handshake 再包 TDS）。SQL Server 2025 終於把眾多自家工具與功能升級至 TDS 8.0 / TLS 1.3，例如 sqlcmd.exe 到 Linked Servers。

預設 OLEDB 19 driver 強制加密。Linked Server 預設可能因為憑證不被信任而建立失敗——若需要可改用 OLEDB 18，或改連線字串容許 trust server certificate。

Breaking changes：https://learn.microsoft.com/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2025

RSA 加密支援 OAEP padding#

過去 SQL Server 對 RSA 使用 PKCS 1.5 padding，已知存在弱點。SQL Server 2025 採用 PKCS 2.X 的 OAEP（Optimal Asymmetric Encryption Padding）。需 dbcompat 170，並建立新金鑰。

密碼雜湊 PBKDF（RFC 2898）#

改用 PBKDF（password-based key derivation function） 進行多輪雜湊，符合 NIST SP 800-63b 指引。

• 新建或變更 login 都使用新演算法
• 登入時若偵測到舊演算法，會自動升級
• 登入可能會多幾毫秒延遲

Linux 上的自訂密碼策略#

SQL Server on Linux 終於可透過 mssql.conf 與 adutil 套用密碼策略（複雜度等），對齊 Windows 體驗。

效能#

效能改善分為三類：應用可用性與並行（concurrency）、tempdb 強化、查詢最佳化與管理。

Optimized Locking（最佳化鎖定）#

兩個關鍵概念#

Optimized Locking 由兩部分構成：

• Transaction lock：以單一 TID lock（XACT lock）取代為大量列 lock
• Lock After Qualification（LAQ）：先過濾、後加 lock 的「lock-free predicate evaluation」

基於 ADR#

利用 Accelerated Database Recovery（SQL Server 2019 引入）的 row versioning。每個版本都有 transaction ID（TID），可作為鎖定依據。

啟用 Optimized Locking 三件事：

ALTER DATABASE <db> SET ACCELERATED_DATABASE_RECOVERY = ON;
ALTER DATABASE <db> SET OPTIMIZED_LOCKING = ON;
ALTER DATABASE <db> SET READ_COMMITTED_SNAPSHOT = ON;

Azure SQL 預設已開啟前兩項，且不可關閉；RCSI 可關閉。

兩個典型痛點被消滅#

1. 鎖定升級（Lock Escalation）#

UPDATE 大量列觸發 lock escalation → 取得 OBJECT X lock → 影響其他不相關的列更新。Optimized Locking 改用 XACT lock，不再累積大量列 lock，自然就沒有 lock escalation。

範例（不啟用時）：

USE AdventureWorks;
DECLARE @minsalesorderid INT;
SELECT @minsalesorderid = MIN(SalesOrderID) FROM Sales.SalesOrderHeader;
BEGIN TRAN;
UPDATE Sales.SalesOrderHeader
   SET Freight = Freight * .10
 WHERE SalesOrderID <= @minsalesorderid + 10000;
-- 觀察 sys.dm_tran_locks，會看到 OBJECT X lock，其他 session 無法併行

啟用後：每個 transaction 各持自己的 XACT lock，不阻塞彼此。

2. Lock After Qualification#

UPDATE Sales.SalesOrderHeader
   SET Freight = Freight * .10
 WHERE PurchaseOrderNumber = 'PO522145787';  -- 用 PO 找而非主鍵

未啟用 LAQ 時，SQL Server 在判斷 row 是否符合 predicate 之前就先取 lock。同時對另一個 PurchaseOrderNumber 做更新便會被阻塞。

啟用 LAQ（以 RCSI 為基礎）後，先評估 predicate 再 lock，兩個 session 互不干擾。

Optimized Locking 的兩個阻塞情境都「無需改 code」即可消除——這是它最大的價值。

tempdb Resource Governance（tempdb 空間治理）#

Resource Governor 自 SQL Server 2008 已治理 CPU、記憶體、MAXDOP、I/O。SQL Server 2025 新增 tempdb 空間 治理。

新的 WORKLOAD GROUP 選項：

• GROUP_MAX_TEMPDB_DATA_MB
• GROUP_MAX_TEMPDB_DATA_PERCENT

設定 default workload group 會影響所有使用者，等同對 tempdb 強制設限——務必小心。

範例：限制特定應用的 tempdb 用量#

ALTER RESOURCE GOVERNOR RECONFIGURE;

CREATE WORKLOAD GROUP GroupforUsersWhoDontKnowSQL
WITH (GROUP_MAX_TEMPDB_DATA_MB = 100);

ALTER RESOURCE GOVERNOR RECONFIGURE;

USE master;

CREATE FUNCTION dbo.ResourceGovernorClassifier()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @WorkloadGroup SYSNAME;
    IF APP_NAME() = 'GuyInCube'
        SET @WorkloadGroup = 'GroupforUsersWhoDontKnowSQL';
    ELSE
        SET @WorkloadGroup = 'default';
    RETURN @WorkloadGroup;
END;

ALTER RESOURCE GOVERNOR
    WITH (CLASSIFIER_FUNCTION = dbo.ResourceGovernorClassifier);
ALTER RESOURCE GOVERNOR RECONFIGURE;

如果該應用試圖讓 tempdb 失控成長，會立刻收到：

Msg 1138, Level 17, State 1, Line 3
Could not allocate a new page for database 'tempdb'
because that would exceed the limit set for workload group
'GroupforUsersWhoDontKnowSQL', group_id 256.

其他 tempdb 強化#

tempdb 啟用 ADR#

ALTER DATABASE tempdb SET ACCELERATED_DATABASE_RECOVERY = ON;

需重新啟動 SQL Server。tempdb 不需要快速 recovery，但可受益於：

• 快速 rollback
• 較少的 log 空間使用

tmpfs 支援（Linux）#

Linux 的 tmpfs 由虛擬記憶體（RAM + swap）支撐。SQL Server 2025 允許把 tempdb 的 data 與 log 檔放在 tmpfs。

• 透過 mount 限制 tmpfs 最大值
• 透過 SQL Server 控制 tempdb 檔案上限
• 細節：https://learn.microsoft.com/sql/linux/sql-server-linux-tmpfs-tempdb

RAM 是寶貴資源——啟用前必須評估：避免使用到 swap（否則就失去使用 tmpfs 的意義）；同時要確認 buffer pool 不致被擠壓。

查詢最佳化與執行#

OPTIMIZED_SP_EXECUTESQL#

sp_execute_sql（SQL Server 7.0 引入）是參數化最常見的方式（ADO.NET 等 driver 預設使用），但因為沒有 compile lock，高並行時可能出現多份相同的快取計畫。

SQL Server 2025 新 ALTER DATABASE 選項：

ALTER DATABASE <db> SET OPTIMIZED_SP_EXECUTESQL = ON;

強制針對相同的查詢取得 compile lock，避免快取膨脹。可用 sys.dm_exec_cached_plans 觀察。

Cardinality Estimation（CE）Feedback for Expressions#

SQL Server 2014 引入新 CE 模型（dbcompat 120）。SQL Server 2022 加入 CE Feedback，會「學習」改善高敏感的查詢。SQL Server 2025 新增涵蓋更多情境（例如同一查詢中不同的 join containment）：

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK_FOR_EXPRESSIONS = ON;

需 dbcompat 160+。

若使用 LEGACY_CARDINALITY_ESTIMATION = ON，CE Feedback 與 CE Feedback for expressions 都不會生效。

Optional Parameter Plan Optimization（OPPO / OPSPO）#

PSPO（SQL Server 2022）對於範圍可區分的參數有效，但對「參數可為 NULL」的查詢無能為力：

SELECT column1, column2
FROM Table1
WHERE column1 = @p OR @p IS NULL;

過去只能 table scan。OPPO 解決：

• NULL 時 → table scan
• 非 NULL → 用 index
• 需 dbcompat 170
• 開關：OPTIONAL_PARAMETER_OPTIMIZATION

DOP Feedback 預設開啟#

SQL Server 2022 引入 DOP Feedback；SQL Server 2025 在 dbcompat 160+ 時 預設開啟。

查詢管理#

Columnstore index 三項強化#

• Non-clustered columnstore index 支援 ordering
• Ordered columnstore index 可線上建立／重建——需 tempdb 空間且 MAXDOP = 1
• Shrink 支援包含 varchar(max)、nvarchar(max)、varbinary(max) 的 columnstore page

Query Store on Secondary Replicas（正式 GA）#

SQL Server 2022 釋出時此功能被 trace flag 12606 鎖在 production 之外。SQL Server 2025 正式上線，無需 trace flag。

運作機制：

flowchart LR
    A["Secondary 上的<br/>Query Store 記憶體結構"] -- "AG 通道串流" --> B["Primary 的<br/>Query Store 系統表"]
    B -- "AG 同步（一般 log）" --> C["Secondary<br/>系統表"]
    C --> A

• 啟用為「all-or-nothing」——在 primary 一指令影響全部 replica
• 串流回 primary 有少許延遲（避免淹沒通道）
• AG 流量較高優先；query store 流量較低優先
• failover 後 SQL Server 知道誰是新的 primary 可寫
• 系統表加上 replica ID

Persisted Stats on Readable Secondaries#

過去 secondary 的 temporary stats 放 tempdb，重啟即失。現在配合 query store 啟用後，送回 primary 持久化到系統表，再透過 AG 同步回 secondary。

即使你不打算使用 query store，也必須在 secondary 啟用，因為它就是「回送」通道。

可用性（Availability）#

Always On Availability Groups（AGs）#

SQL Server 2025 對 AG 的強化是隱形 hero——基於工程師 Dong Cao 的團隊長期累積。多數只要升級就能享有，不需特別設定。

Failover 改進#

為持久故障加快 failover#

過去：cluster 偵測到 health check 或 lease timeout 會先重啟 AG resource 一次，再決定是否 failover。對暫時性問題很好，但對持久故障是延誤。

SQL Server 2025 強化：將 cluster 設定 RestartThreshold = 0 時，能正確讓 SQL Server 立即觸發 failover。

何時建議改：若 ERRORLOG / Cluster Log 顯示頻繁的 restart 解決後又 failover，調 0；否則先調查 transient 重啟的原因。

解開「Not Synchronizing」之謎#

短暫的 quorum 失效不應讓 AG 永遠停留在 Not Synchronizing。SQL Server 2025 修正了這類 transient quorum loss 的反應邏輯，讓 AG 能自動恢復。已 backport 到 SQL Server 2019/2022 CU。

非同步 page request 派送#

當 AG 找尋 common recovery point 時可能要 undo of redo，需要從另一個 replica 取大量 page。過去串列送出，網路延遲下會變慢。現在改為非同步、批次請求，網路延遲時受益最大。

Tuning、Configuration、Diagnostics#

Flow control 可手動微調#

Flow control 的設計是怕 secondary 跟不上，於是 primary 自動降速。但如果是「網路慢、secondary 處理快」，flow control 反而變成枷鎖。

SQL Server 2025 新增伺服器設定 max ucs send boxcars，允許手動調高。

觀察線索：

• 計數器 Database Flow Control Delay
• DMV sys.dm_hadr_database_replica_states.log_send_queue_size
• secondary 的 Log Bytes Flushed/sec 是否維持預期速度

需 RECONFIGURE 並重啟。

Group commit 等待時間可調#

過去 SQL Server 2016 開始固定 10ms 的 group commit delay；網路非常快時反而拖累 throughput。新設定：

EXEC sp_configure 'availability group commit time (ms)', 5;
RECONFIGURE;

範圍 1–10，0 為預設 10ms。需 RECONFIGURE 但不需重啟。

其他配置強化#

• Listener 可移除特定 IP（不必整個重建 listener）
• read-only / read-write routing 可設為 NONE 以恢復預設
• Windows Cluster Log 加入更多 health check timeout 診斷資訊（CPU、可用記憶體、磁碟讀寫平均時間）

Distributed Availability Groups（DAG）強化#

DAG 支援 Contained AGs（CAG）#

CAG 把 master 與 msdb「進駐」AG，failover 後 login 與 SQL Agent job 自動跟著走。SQL Server 2025 讓 DAG 兩端都可使用 CAG，並在多層 failover 後仍維持一致。

DAG 同步效能改善#

過去 DAG 假設 forwarder 用 sync commit；如果 forwarder 實際是 async，仍會以 sync 訊息傳遞。SQL Server 2025 真正尊重 forwarder 的 async 設定，避免不必要等待。

仍建議 DAG 兩端使用相同 commit mode；此改進是面對「真實世界 mismatch」的合理化。

Backup / Restore#

ZSTD 備份壓縮#

SQL Server 2025 引入 ZSTD（ZStandard）為第三種備份壓縮演算法（其他兩種：MS_EXPRESS、Intel QAT_DEFLATE）：

BACKUP DATABASE AdventureWorks
TO DISK = 'c:\temp\adw.bak'
WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = LOW),
     INIT, FORMAT;

• LEVEL = LOW / MEDIUM / HIGH，預設 LOW
• LOW 速度最快，HIGH 壓縮率最高
• 即使是 HIGH 等級，CPU 用量大約與 MS_EXPRESS 相當

伺服器設定 backup compression default 也可設為 ZSTD，但無法指定 LEVEL，會使用預設 LOW。

Secondary 上做 Full / Differential 備份#

SQL Server 2012 起，secondary 上只能做 COPY_ONLY 與 transaction log 備份。

SQL Server 2025 終於支援 full 與 differential 備份在 secondary 執行。實作上需在 primary 與 secondary 之間同步 checkpoint。

DECLARE @DBNAME NVARCHAR(128) = N'YourDatabaseName';
IF (sys.fn_hadr_backup_is_preferred_replica(@DBNAME) != 1)
BEGIN
    PRINT 'This is not the preferred replica';
    RETURN;
END
BACKUP DATABASE @DBNAME
TO DISK = N'C:\Backups\YourDatabaseName.bak'
WITH COMPRESSION;

備份到 Azure Immutable Storage#

為對抗勒索軟體，Azure Immutable Storage 提供 WORM（Write Once Read Many）特性。SQL Server 過去的 BACKUP TO URL 演算法需要多次 commit，無法相容。

SQL Server 2025 改成「整份 backup set 只 commit 一次」，正式支援備份到 Azure Immutable Storage。

隱藏寶石#

ABORT_QUERY_EXECUTION#

場景：某查詢正在拖垮系統（耗 CPU、影響其他關鍵查詢），又無法立刻改源頭應用。透過 query store hint 直接「封殺」此查詢。

-- 從 query store 找到問題查詢的 query_id
-- 套用 hint
EXEC sys.sp_query_store_set_hints
    @query_id = <id>,
    @query_hints = N'OPTION (USE HINT(''ABORT_QUERY_EXECUTION''))';

之後任何試圖執行該查詢都會收到：

Msg 8778, Level 16, State 1, Line 1
Query execution has been aborted because the
ABORT_QUERY_EXECUTION hint was specified

In-Memory OLTP 可拆除#

SQL Server 2016 的 In-Memory OLTP（代號 Hekaton）一旦啟用，過去無法移除而不刪庫。SQL Server 2025 終於支援移除 memory-optimized table、檔案與 file group，連帶卸下 In-Memory OLTP「引擎」元件。

步驟：https://learn.microsoft.com/sql/relational-databases/in-memory-oltp/memory-optimized-container-filegroup-removal

PolyBase 改善#

不再需要 PolyBase Services#

讀 Parquet、Delta 等格式的 OPENROWSET 可直接執行，不必再安裝 PolyBase Services 與啟用 polybase enabled：

SELECT *
FROM OPENROWSET(
    BULK 'abs://nyctlc@azureopendatastorage.blob.core.windows.net/yellow/puYear=2001/puMonth=1',
    FORMAT = 'parquet'
) AS taxidata;

Managed Identity 支援#

PolyBase 也能用 Azure Arc system-assigned Managed Identity 安全存取 Azure Blob Storage 與 Azure Data Lake Storage（與第 6 章中 Azure AI 的設定方式相同）。

記憶體健康診斷：sys.dm_os_memory_health_history#

新 DMV 以環狀緩衝區方式，每 15 秒一筆、最多 256 筆，記錄記憶體可分配量、可回收快取量、Top 5 memory clerks（JSON）、severity_level（1 = 正常）。

範例：

SELECT committed_kb, committed_target_kb FROM sys.dm_os_sys_info;
SELECT * FROM sys.dm_os_memory_health_history;

人為製造記憶體壓力觀察：

EXEC sp_configure 'show advanced', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', 600; RECONFIGURE;

之後 severity_level 會升至 3，allocation_potential_memory_mb 顯著下降——典型的記憶體吃緊狀態。

全球最快的資料庫#

「調校 SQL Server 引擎像在調賽車——但它必須在沒有專家駕駛時也能順跑。我們的團隊持續探索如何讓 SQL Server 跟上最新硬體與真實客戶工作負載。在 SQL Server 2025 開發中，我們把 Dave Cutler 拉進與 Windows Server OS 團隊的深度最佳化討論——結果不只 SQL Server 變快，整個 Windows Server 客戶都受惠。」

— Thierry Fevrier，Microsoft Partner Software Engineer

作者實測 HammerDB TPROC-H 在 Windows Server 2025 + SQL Server 2025 比 SQL Server 2022 提升約 5–8%。

「許多客戶只要升級就能體會更好的查詢效能。」

持續調校的引擎#

「SQL Server 2025 持續推進創新——應用無需改 code 就能享受效能與可靠度提升；同時引入眾多長期被期待的能力，並透過深度的 JSON 與 vector 支援開啟現代 AI 應用。」

— Naveen Prakash，Microsoft VP of Engineering

引擎更新告一段落，下一章把焦點轉向統一資料平台 Microsoft Fabric。