SQL Server 在2024年11月開始進行社區私有預覽（鏈接），由于涉及AI能力，我也是第一時間申請了內側資格，悲劇的是，直到2025年2月，才拿到預覽版的測試資格-.-，此時已經是CTP1.3了，也就是內側的第四個版本了。

但whatever，late better than never。下面根據我的初步測試，做一些分享。

當前的測試的版本為：

原生向量支持與DiskANN向量索引

SQL Server作為一個典型的商業數據庫，一直喜歡搞大而全，各種全家桶全塞進來，現在流行的說法叫“一站式”。基本邏輯是每個sql server版本都會結合當時流行的趨勢和技術，將該技術集成進SQL Server，下面是一個簡單的回顧

歷代SQL Server結合當時背景的新增功能分析

SQL Server 2008 - 層級結構 (HierarchyID) 和地理信息 (Spatial Data):

 Web 2.0 興起，層級數據和位置服務應用普及。HierarchyID 高效管理組織結構等層級數據，Spatial Data 支持位置服務，滿足 Web 2.0 時代對復雜數據管理和地理位置應用的需求。

SQL Server 2012 - 內存數據庫 (In-Memory OLTP):

電商等高并發 OLTP 應用爆發，磁盤 I/O 成性能瓶頸。另外這個時代SSD還是貴的沒邊，穩定性還沒這么靠譜的存儲。內存優化表 減少磁盤 I/O，大幅提升高并發 OLTP 性能，應對電商、金融等對極致性能的迫切需求。

但目前來看，這個功能使用率并不是很高，該功能通常通過外掛的緩存系統實現，比如Redis。

SQL Server 2014 - 列存儲 (Columnstore):

大數據分析興起，傳統行式存儲分析查詢效率低下。列式索引優化分析查詢，大幅提升大數據倉庫性能，順應大數據分析流行趨勢，滿足企業數據洞察需求。

SQL Server 2016 - JSON 支持 (JSON Support):

Web 服務和 NoSQL 流行，JSON 成 Web 數據交換主流格式。JSON 支持 允許存儲和查詢 JSON 數據，靈活適應 Web 服務和半結構化數據，擁抱 NoSQL 趨勢，拓展應用場景。

SQL Server 2017 - 圖數據庫 (Graph Database):

社交網絡、推薦系統等關系復雜應用興起，傳統關系數據庫效率不高。圖數據庫 支持建模復雜關系，高效處理社交網絡、推薦系統等應用。

SQL Server 2019 - HTAP (Hybrid Transactional/Analytical Processing):

實時數據分析需求強烈，傳統數據倉庫延遲高。HTAP 能力 支持實時分析，提升決策效率，符合實時業務監控和快速決策需求，順應混合處理趨勢。

SQL Server 2022 - 賬本 (Ledger Tables):

數據安全和合規性日益重要，區塊鏈技術火的一塌糊涂（比特幣價格起飛），需要防篡改數據記錄。賬本表 提供防篡改數據記錄，增強數據完整性和可信度，滿足審計、合規等對數據可信有高要求的場景，擁抱區塊鏈技術，提升數據安全水平。

SQL Server 2025 - 向量數據庫 (Vector Database):

當下AI的爆發年代來看，需要向量數據庫的背景無需多說，向量數據庫在應用層面主要用于RAG、語義理解、大規模向量數據處理和多模態融合，并能顯著降低向量檢索計算成本。是AI應用中最重要的基礎設施之一。

原生向量類型支持

SQL Server增加內置的Vector字段，最高支持1998維度（猜想是因為每個向量都是32精度的float，1998維度正好不超過SQL Server每頁的8K存儲，從而不溢出），通過測試可以發現，內部存儲使用varbinary數據作為底層數據，做了一個簡單的測試，通過新增變量類型為Vector，或表列定義為Vector列實現，如圖所示:

基于DiskANN的向量相似度檢索

DiskANN介紹

DiskANN基于微軟2019年發表的論文《DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node》。在此之前，向量搜索領域中一個流行的主要算法是HNSW（分層可導航小世界圖），這是一種利用多層圖結構進行搜索的算法。HNSW的核心特點是涉及大量的隨機內存訪問，因此該算法需要消耗大量內存資源，要求原始向量和圖數據都必須常駐內存中。

圖.HNSW圖查找示例

我們以阿里云的Millivs托管服務為例，如果涉及1千萬的512維向量數據為例，推薦資源如下：

圖. Millivs對于千萬級512維向量的推薦資源

這種資源要求所帶來的成本較高，會比較多限制AI的落地。針對于此，DisnANN的核心目標是，用有限的內存（幾十GB）+大容量的SSD盤，支撐單節點存儲和搜索十億級別的數據集，同時保持高性能（低延遲、高召回率）。

DiskANN的核心算法是Vamana圖，本質上是一種構建近似最近鄰圖的方法，它為每個節點構建一個有限數量的出邊，這些出邊連接到該節點的近似最近鄰。與HNSW的多層結構不同，Vamana構建單層圖，但通過精心設計的圖構建過程確保搜索效率。舉個例子理解是Vamana圖就像一張城市地圖，每個數據點是地圖上的一個地點，邊代表地點之間的鄰近關系。DiskANN 的搜索過程就像在地圖上導航，從某個起始點出發，沿著邊不斷“走”到離目標地點最近的位置。

同時DiskANN還做了一些優化，來適應磁盤換內存的場景，例如：

• k-means聚類（分而治之），降低建圖的內存需求。
• PQ量化（數據壓縮），減少內存和計算量。
• SSD定長數據（高效存儲），加速讀取。
• 入口節點和鄰居放內存（緩存熱點），減少SSD訪問。
• beam-search（并行搜索），提升搜索效率。

 下面是根據論文，做了一個DiskANN的簡單數據：

SQL Server中相似度搜索使用方式

當前在SQL Server的CTP1.3版本中，向量搜索的核心函數主要是VECTOR_DISTENCE,可以結合在傳統的T-SQL中使用，目前該函數還比較初級，當前僅支持余弦相似度、歐式距離和點積。一個簡單的示例如下：

-- 創建一個包含向量字段的表
CREATE TABLE VectorTable (
    ID INT PRIMARY KEY IDENTITY(1,1),
    Description NVARCHAR(100),
    EmbeddingVector VECTOR(10) -- 創建10維向量字段
);

INSERT INTO VectorTable (Description, EmbeddingVector)
VALUES 
    ('示例項目1', '[0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0]'),
    ('示例項目2', '[0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5]'),
    ('示例項目3', '[0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2, 0.1, 0.0]');


DECLARE @queryVector VECTOR(10) = '[0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 0.1]';



-- 使用余弦相似度查找最相似的向量
SELECT 
    ID, 
    Description,
    vector_distance('cosine' , @queryVector, EmbeddingVector)
FROM VectorTable

余弦相似度的結果如下：

圖. 計算余弦相似度

同時SQL Server也支持使用和傳統的關系數據共同作用，進行相似度查詢，例如該例子，結合where條件，幫助用戶通過where做過濾，同時選出top 5相似度的產品：

  -- 假設我們有一個查詢向量（可能來自用戶當前正在查看的產品）
DECLARE @query_vector VECTOR(512) = CAST(CONCAT('[', REPLICATE('0.15,', 511), '0.15]') AS VECTOR(512));

-- 查找與當前產品最相似的5個產品（使用余弦相似度）
SELECT top 5
    id,
    category,
    description,
    vector_distance('cosine' , @query_vector, vector) AS similarity_score
FROM 
    VectorDemo
where category = 'Clothing'
ORDER BY 
    similarity_score

結果如下：

圖.余弦相似度計算結果

相似度搜索的性能

由于當前我拿到的是私有預覽版的sql server，并沒有合適的幫助文檔，因此不確定我的使用方式是否正確，按我的理解，可能需要針對向量列單獨加索引，但目前沒看到加索引的方式，下面的測試是基于沒有加索引的測試。測試的數據量如下：

當前我們的測試表大約是200W+的數據，每列包含512維的向量，大約數據占用是6G左右，當我做一個簡單的相似度搜索時，可以看到

雖然查詢完成時間在334毫秒，從邏輯讀（80萬的邏輯讀*8K每次讀取，基本等于數據量大小）來看，基本走了全表掃描，而CPU使用也是非常高，基本需要1個CPU 100%，2.3S時間。

當前查詢完成快是數據已經常駐內存，那么如果我將sql server使用內存調低，涉及到IO讀寫呢？比如當前數據量維6.9G，我將內存使用上限調整為6G會發生什么：

由于開始涉及物理讀寫，我們看到整個查詢時間來到不可接受的節奏。大量的預讀和IO操作使得CPU時間翻倍，同時整體時間增長50倍倍。

那么我們使用選擇性很高的索引呢？

可以看到，category='test'的選擇性非常高，導致向量相似度搜索成本直接通過IndexSeek+向量搜索完成。

后續等待更多文檔出來再進一步觀察，當前的觀察是，如果沒有對向量增加索引，則搜索基本需要全量比對+排序。如果用于實際生產，基本難以接受。

其他AI相關函數支持

VECTOR_NORM（向量標準化）

本例中VECTOR_NORM(image_embedding, ‘norm2’) > 3 主要作用：

• 去除純色背景（因向量范數接近零）
• 去除模糊圖像（因特征信息少，范數較小）
• 去除異常數據（因數據錄入錯誤，導致范數極小或無效）

 VECTOR_NORMALIZE（向量歸一化）

該函數解釋也比較簡單，就是將向量的上限變為1，比如當前最大值是5，則對應的4變為0.8。一個簡單的例子：

AI服務集成與T-SQL擴展

sp_invoke_external_rest_endpoint

直接通過 T-SQL 調用外部的 HTTPS REST 或 GraphQL 接口。簡單來說，它讓 SQL Server 數據庫可以像客戶端一樣，直接和外部服務（比如 Azure Functions、Power BI、OpenAI API 、DeepSeek API等）交互。

想象你在 SQL Server 里寫了個腳本，但需要外部服務（比如翻譯文本、計算匯率、調用大模型等）。以前你得寫個外部程序（比如用 Python 或 C#）去調用服務，再把結果寫回數據庫。現在，sp_invoke_external_rest_endpoint 可以做到數據不出數據庫即可完成服務。

其實外部調用的優勢和劣勢我也簡單做了一個總結，

優勢：

• 數據就地處理，減少數據搬運（同時減少安全面）
• 統一的事務與安全機制（ACID支持，數據庫權限、證書支持）
• 簡化架構與減少依賴（集中化帶來開發便利）
• 方便運維（集中化帶來運維便利）
• 快速原型驗證（驗證后遷移服務層）

  劣勢：

• 數據庫負載與性能沖突
• 數據庫難以Scale-out
• 難以調試（T-SQL相比編程語言難以調試）
• 語言/生態局限（支持的Python包有限）
• 安全問題（需要數據庫能夠訪問外部服務，需要額外啟用防火墻）
• 數據庫中生態極差（主流語言支持豐富的AI/ML庫）

下面是一個簡單的例子，我將SQL Server數據庫的日志發送給大模型，尋求性能優化建議：

DECLARE 
    @endpoint_url NVARCHAR(200) = N'https://',
    @api_key NVARCHAR(100) = N'sk-or-v1',
    @logs_context NVARCHAR(MAX),
    @payload NVARCHAR(MAX),
    @response_status_code INT,
    @response_message NVARCHAR(MAX);

-- 步驟1：獲取最新的 SQL Server 日志信息作為上下文
SET @logs_context = N'2025-02-26 14:35:15.45 spid51 Query execution time exceeded 1s for SELECT * FROM Sales.Orders JOIN Sales.OrderDetails ON Orders.OrderID = OrderDetails.OrderID WHERE OrderDate > ''2025-01-01''. Table scan detected on Sales.OrderDetails due to missing index on OrderID. + 2025-02-26 14:35:18.19 spid47 CPU usage reached 92% for 30 seconds. High lock contention detected on table Sales.Orders. + 2025-02-26 14:35:19.19 spid47 Buffer pool hit ratio dropped to 7%. Memory pressure detected, available memory: 512 MB.';

-- 步驟2：構造請求體
SET @payload = N'{
    "model": "google/gemini-2.0-flash-001",
    "messages": [
        {"role": "system", "content": "You are a SQL Server expert."},
        {"role": "user", "content": "以下是我的SQL服務器日志信息：' 
         + @logs_context 
         + N'。請給出可能的性能優化或故障排查建議。"}
    ]
}';

-- 步驟3：構造請求頭
DECLARE @headers NVARCHAR(MAX);
SET @headers = CONCAT(N'{"Content-Type": "application/json", "Authorization": "Bearer ', @api_key, '"}');

-- 步驟3：調用 sp_invoke_external_rest_endpoint 發送 POST 請求
EXEC sp_invoke_external_rest_endpoint
     @url = @endpoint_url,
     @payload = @payload,
     @method = 'POST',
     @headers = @headers,
     @response = @response_message OUTPUT,
     @timeout = 60; 

-- 步驟5：查看返回結果
SELECT @response_message AS [OpenRouter Response];

看到結果：

圖. 調用外部模型返回的結果

返回的部分JSON截圖：

圖. 部分返回結果JSON化

sp_execute_external_script

在使用庫數據庫層直接完成推理或特征提取，sp_execute_external_script是 SQL Server 提供的一個系統存儲過程，允許在 SQL Server 中直接執行外部腳本語言（如 R、Python 或 Java）的代碼，并且可以與數據庫中的數據無縫交互。它是 SQL Server 集成機器學習和高級分析能力的核心組件之一。

一個簡單的例子：調用 Python + Hugging Face Transformer 做情感分析

圖. 使用T-SQL調用外部Python包

結果：

圖. 情感分析場景結果

支持 LangChain、Semantic Kernel、EF 等流行 AI 框架

這部分是在SQL Server之外完成的，本質上就是在這些流行的框架中，增加了對SQL Server的驅動支持，其實沒什么好說的，例如：

在langchain中，直接支持SQL Server作為數據存儲。

圖. 將SQL Server作為向量數據源

直接在langchain中進行相似度搜索

圖. SDK直接進行相似度搜索

圖. 在C#的ORM直接支持相似度搜索

小結

??本文基于SQL Server 2024年11月社區私有預覽（CTP1.3版本）的初步測試，分享了新功能的體驗。SQL Server 2025新增了原生向量支持和DiskANN向量索引，適應當前AI應用需求，可用于RAG、語義理解等場景，支持最高1998維向量存儲及余弦、歐氏距離等相似度檢索。測試中發現，向量搜索性能可能因缺乏索引或數據未駐留內存而下降，特別是在IO密集場景下表現不理想，但這可能與測試時缺乏官方文檔、使用方法不當有關，待后續資料完善后再進一步驗證。此外，新功能還包括向量標準化

   通過sp_invoke_external_rest_endpoint和sp_execute_external_script實現外部服務調用和腳本執行，擴展了應用場景，但也帶來了一些性能和調試上的挑戰。同時，SQL Server對LangChain、Semantic Kernel等框架的支持也增強了其生態兼容性。總的來說，SQL Server 2025在功能整合上邁出了重要一步，但實際效果還有待更多文檔支持和優化驗證。