SQL Server 2025 簡介

自 2022 版後，等了 2 年多，眾人疑慮 SQL Server 是否還有企業內獨立安裝的版本，或僅存 Azure 的 SQL 服務？微軟的 SQL 團隊信守諾言，在今年(2025)底會推出新的 SQL Server 2025 版本，這也滿足了一般企業兩類需求：

• 提供了購買 SA 保證可升級或面臨 EOS 舊版必須升級的客戶，可以持續升級，而非強迫換成雲。
• 確保在其他雲(例如 AWS、GCP)上，可以透過虛擬機(IAS)安裝與使用 SQL Server。

集大成的資料平台

SQL Server 始於 1989 年微軟與 Sybase 合作，讓其在 OS/2 平台上運作，迄今 36 年，歷經多世代資訊演進：

• 從關聯式資料庫初期的大廠爭霸，檔案型的 dBase、Clipper、Foxpro…消逝，系統型的 Sybase、Informix…被購併等，至今付費的產品市場上，大約只有 Oracle 與其並稱。
• 網際網路時代的異質整合，從 2000 年的 xml 到 2010 年的 json，SQL Server 耗了 25 年，終於原生支援 json 資料類型，納入了曾經熱鬧過的NoSQL。
• 大型文章的搜尋比對，從 SQL Server 7.0 的全文檢索演進到 2025 年透過大語言模型的語意近似，換言之，查詢條件可以混合不同的篩選方式，讓整合與應用資料更有彈性：
  • 值的大於、小於、等於(=、>、<、like)
  • 字與詞的全文檢索(contains)
  • 搭配大語言模型的語意近似(vector_search、vector_distance)

除了上述大者，SQL Server 整合的技術還有：.NET CLR 自訂資料類型(2005)、大型檔案(FileStream、FileTable 2008+)、大量欄位記載多屬性的稀疏欄位(Sparse Column 2008)、空間與地理資訊(Spatial 2008)、多層次的階層資料(HierarchyID 2008)、資料行儲存結構(Columnstore 2012)、記憶體最佳化的高頻交易(In-Memory OLTP 2014)、節點與關係的 Graph Tables(2017)…。至此，可以看到 SQL Server 以資料平台立身，30 多年來把資訊界不同時期；流行了三~五年的風潮都存了下來。相關討論可以參閱 Blog 大江東去。

SQL Server 在新技術上從不爭第一，但求整合進成熟技術，畢竟要將新技術有效且穩定地整併到龐大的 SQL 引擎需要經費與時間，且要等到該新技術證明有市場且可以整合後。

曾立於各浪濤之上的品牌/產品/企業慢慢淡出資訊界，而 SQL Server 留下了資料結構與演算法。

單就 SQL Server 2025 針對引擎的強化而言，依微軟的說法有超過 40 處，在此稍舉其大者，先列舉關於應用程式開發的部分。

關於開發的部分

可以點選文件的超連結，進一步檢視範例與說明：

• 向量(Vector)資料類型、索引與距離計算，並宣告搭配的 AI 大語言模型，可用以開發檢索增強生成(Retrieval Augmented Generation RAG)應用程式
• Json 資料類型、索引與強化相關 Json 查詢函數。
• 正則表示式(Regular Expression)與相關函數¹。
• 呼叫 REST API。
• 新增與強化多個 T-SQL 函數。
• 提供 Change Event Streaming 將 DML(沒有 DDL) 造成的紀錄變更傳給 Azure Event Hubs，讓同步資料從交易紀錄讀取變異(Pull)改成有變異後，以 event streaming 的方式傳送出去的 Push 模式。
• 最佳化鎖定，減少鎖定範圍與鎖定提升(lock escalation)。
• 系統函數持續以批次模式優化，以提升效率。
• 改善 columnstore 索引，讓 nonclustered 的 columnstore 索引也可以排序與線上建立/維護。並改善 clustered columnstore 索引的 DBCC shrink 作業。

關於管理的部分

• Tempdb 資料空間資源治理：以資源管理員限制連接對 tempdb 空間的使用，避免某個作業用爆了 tempdb，讓其他作業一起遭殃。
• 增加 database scoped configuration 可調整的項目，讓每個資料庫更獨立自主，依其應用特性設定，而不被整個 Sql Server instance 限制。
• 持續強化可用性群組(Availability Group)，但因為是多項細節特性，難以在此詳述。總歸就是強化整座 AG 的穩定性與容錯移轉效能。此外，對唯讀次要節點強化了許多：
  • 自動建立、更新並保留資料分布統計，讓只針對唯讀次要的查詢也可以正確的統計找執行計畫。
  • 查詢存放區(Query Store)也可以保留次要唯讀節點所產生的執行計畫與相關統計。
  • 各種資料備份也可以在次要節點上執行。
  AG 次要唯讀節點是用來提供報表查詢的，與主要節點是為了交易的增刪修查用途不同。要能有滿足次要節點自己查詢的資料分布統計，與查詢存放區的執行查詢紀錄，這才能有好的執行計畫並檢討執行狀況。換句話說，SQL Server 2025 能較有效地發揮次要節點的查詢功能。
• 將各種安全機制，如加密、網路協定深化，並讓前端輔助工具一併採用。另外，變更某個登入的定義或權限後，SQL Server 以往的版本會清掉所有的登入/權限快取並重新載入，這拖慢大量使用者同時線上存取的效能。2025 版後僅針對該特定登入更新快取。
• 備份壓縮改採 ZSTD 演算法，更有壓縮率與效率。
• 刪除所有 In-Memory OLTP 物件後，支援移除記憶體優化容器和檔案群組

持續強化雲地整合

雲地混合是個趨勢，有歷史背景或業務核心受限各種需求；導致部分 IT 系統須在地的企業，很難純雲。但各種新技術與平台/超大運算力往往只有雲解決方案，且雲針對特定應用有彈性、效率、便宜(要特別強調，這有一定的前提條件，一般來說採用雲不會比較便宜)…等優勢，讓純地的 IT 也難。換句話說，雲地混合的 IT 會越來越多。

裝於地端的 SQL Server 不僅要與微軟的 Azure 雲密切整合，還努力跨往多雲平台，自 2022 版就開始整合 AWS，而 2025 針對以下面向進一步強化：

• 將資料送往雲
  • 將本地 SQL Server 資料庫近乎即時地鏡像到 Microsoft Fabric。
  • 支援累加式 DML(Insert、Update、Delete)變更串流，使用 CloudEvents 格式(JSON 或 Avro)傳送至 Azure Event Hubs。
• PolyBase 多雲查詢
  • 除了增加 Azure 上的各式服務與資料格式外，也開始逐漸支援 AWS 上的各種格式資料
• Azure Arc 整合支援 Managed Identity
  • 以往與 Azure Arc 整合，以管理並監控各種版本的雲/地SQL Server。2025 版後，可透過 Azure Arc 啟用 Managed Identity，讓 SQL Server 的服務帳號有對應的 Azure Entra ID 身分，以授權 SQL Server 存取 Azure Blob、Key Vault 等資源。無需 SAS Token 或儲存帳戶金鑰，提升安全性與自動化程度。
• 備份至 S3-Compatible 儲存
  • 除了 Azure Blob，SQL Server 2022 開始支援備份至 Amazon，2025 繼續強化與 S3 或 MinIO 等 S3 相容儲存。
• 外部 REST 端點呼叫
  • 新增 sp_invoke_external_rest_endpoint 系統預存程序。可用 T-SQL 直接呼叫提供 REST API 的外部服務，可整合 Azure Functions、OpenAI API以及其他各種雲上的 REST 服務。
• 整合 AI 模型與 Azure AI Foundry
  • 可將 AI 模型部署於本地或雲端，SQL Server 透過 REST API 呼叫，可整合 Azure OpenAI、Ollama、Semantic Kernel 等框架。

整合 AI

SQL 引擎支援 AI，以滿足檢索增強生成(Retrieval-augmented generation RAG)架構在資料端的需求：

• 以宣告的方式指定多種大語言模型(LLM)
• 語意向量的內嵌(Embedding)，也就是以 vector 資料型別儲存從 LLM 回傳之向量值。
• 針對 vector 資料型別建立 DiskANN (Disk Approximate Nearest Neighbor)索引，以加速查詢。
• 向量距離的近似度比較。
• 長文字切成區塊(chunk)。

除了引擎核心支援 AI 當作開發者的基石外，SQL Server 的管理工具 SSMS 在 21 版也整合了 Azure AI Foundry，以 Copilot 的方式輔助開發者寫 T-SQL，或是幫助管理者定義維護排程或尋找問題。

附帶一點，SQL Server 2025 隨附的報表服務是 PBIRS，不再有獨立的 RS。這不是新功能，但可能幫助省授權費。如線上說明所言：PBIRS 適用於所有付費版本的 SQL Server，包括不含軟體保證（SA）的授權版本。

¹ 有些博主(例如著名的 Brent Ozar)舉例在大量資料時，不適合用正則運算，但其例子是將 REGEXP_LIKE 系統函數用在 where 條件，這本就不利 SARG。當然，RegEx 運算複雜，應該要小心對效能的影響。