前言
在大模型RAG应用中，提起向量数据库大家想到的更多的是Chroma和FAISS，微软也紧跟时代的步伐，并且在2025年底发布的 SQLServer 2025 也提供了原生向量支持，此篇将介绍如何在SQLServer 2025里搭建向量数据库环境。
环境准备
软件版本要求
| 组件 | 版本要求 | 说明 |
|---|
| SQL Server | 2025 | 此版本开始支持原生 VECTOR 数据类型 |
| ODBC Driver | 17+ | 用于 Python 连接 SQL Server |
| Python | 3.9+ | 后端运行环境 |
| Ollama | 最新版 | 本地运行 LLM 和嵌入模型 |
本地嵌入模型也可以考虑使用Microsoft Foundry Local，只是模型的支持数量上比较有限，所以此篇使用ollama做演示。
验证 SQL Server 版本
SELECT @@VERSION;
大家需要下载目前最新的SQLServer 2025，从这个版本起微软才开始支持向量数据库。
根据部分文档描述，后续微软可能对相应部分做调整，所以也请留意后续微软的变化。
撰写此篇时是2026年5月4日，从微软下载的SQLServer 2025 Developer版本也是在这一天。
安装 Ollama 及嵌入模型
RAG系统中嵌入模型是很关键的，用于将文本转换为向量表示，从而实现向量检索。
这里为了实现和部署的方便，我们选择的是本地部署Ollama加一个很小的嵌入模型。
brew install ollama
ollama pull nomic-embed-text
ollama list
以上Ollama的安装时在命令模式下用brew安装，在widows下或者macOS下也可以选择桌面安装，相对更容易一些。
本文使用的嵌入模型体积很小，所以基本在国内网络环境也可以很快的下载完。
数据库创建
创建向量数据库
USE master;
GO
IF NOT EXISTS (SELECT name FROM sys.databases WHERE name = 'VectorDB')
BEGIN
CREATE DATABASE VectorDB
COLLATE Chinese_PRC_CI_AS;
END;
GO
数据库的创建跟普通数据库创建没任何区别。
表结构设计
三张表概述
为减少信息冗余，这里我们采用三张表结构设计：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Documents │────▶│ TextChunks │────▶│ VectorIndex │
│ 文档表 │ 1:N │ 文本块表 │ 1:1 │ 向量索引表 │
└─────────────┘ └─────────────┘ └─────────────┘
大体的切分就是：文档信息 -> 文本切块原始信息 -> 文本切块向量数据信息。
文档表 - 存储原始文档
CREATE TABLE Documents (
DocumentId BIGINT IDENTITY(1,1) PRIMARY KEY,
Title NVARCHAR(500) NOT NULL,
Content NVARCHAR(MAX) NOT NULL,
Source NVARCHAR(500) NULL,
Metadata NVARCHAR(MAX) DEFAULT '{}',
CreatedAt DATETIME2 DEFAULT GETDATE(),
UpdatedAt DATETIME2 DEFAULT GETDATE(),
IsDeleted BIT DEFAULT 0
);
文本块表 - 存储分块文本
CREATE TABLE TextChunks (
ChunkId BIGINT IDENTITY(1,1) PRIMARY KEY,
DocumentId BIGINT NOT NULL,
ChunkIndex INT NOT NULL,
ChunkText NVARCHAR(MAX) NOT NULL,
ChunkHash NVARCHAR(64) NULL,
CreatedAt DATETIME2 DEFAULT GETDATE(),
IsDeleted BIT DEFAULT 0,
FOREIGN KEY (DocumentId) REFERENCES Documents(DocumentId)
);
以上两个表跟创建传统表没有任何区别。
向量索引表 - 存储分块文本向量化之后的内容
CREATE TABLE VectorIndex (
VectorId BIGINT IDENTITY(1,1) PRIMARY KEY,
ChunkId BIGINT NOT NULL UNIQUE,
EmbeddingVector VECTOR(768) NOT NULL,
CreatedAt DATETIME2 DEFAULT GETDATE(),
IsDeleted BIT DEFAULT 0,
FOREIGN KEY (ChunkId) REFERENCES TextChunks(ChunkId)
);
留意字段：EmbeddingVector，它的类型是VECTOR。
EmbeddingVector VECTOR(768) NOT NULL
这是 SQL Server 2025 的原生向量类型：
VECTOR(768)：表示 768 维向量，与 nomic-embed-text 模型输出维度一致- 原生支持向量存储，无需像旧版本那样将向量序列化为 JSON 或 Base64
- 向量格式为方括号数组：
[0.123, -0.456, 0.789, ...]
关于如何确定向量类型的维度，这个是需要跟使用的嵌入模型对应的，而如何获知使用的嵌入模型的维度，最简单的方法就是问豆包加交叉验证（避免幻觉）。
需留意，如果不是SQLServer 2025，那么这个表的创建会失败。
创建向量索引
ALTER DATABASE SCOPED CONFIGURATION
SET PREVIEW_FEATURES = ON;
GO
CREATE VECTOR INDEX idx_content_vector
ON dbo.VectorIndex(EmbeddingVector)
WITH (METRIC = 'cosine');
重要，不然后面的VECTOR_SEARCH函数会报错。而且要打开预览版功能，目前添加向量索引还是预览功能，后续应该会在增量补丁里被扶正。
向量化插入与读取
这部分的代码本应放在下一篇讲解，但涉及到如何做向量检索，所以先贴两个关键步骤出来。
插入向量
def create_vector(chunk_id: int, embedding: List[float]) -> int:
embedding_str = '[' + ','.join(str(x) for x in embedding) + ']'
sql = f"""
DECLARE @embedding NVARCHAR(MAX) = '{embedding_str}';
INSERT INTO VectorIndex (ChunkId, EmbeddingVector)
VALUES ({chunk_id}, CAST(@embedding AS VECTOR(768)));
"""
with vdb.get_cursor() as cursor:
cursor.execute(sql)
知识点笔记：
向量格式转换：
- Python:
[0.1, 0.2, 0.3] - SQL Server VECTOR:
[0.1,0.2,0.3]（无空格）
为何使用 NVARCHAR(MAX) 中转：
- 直接
CAST(? AS VECTOR) 参数化查询会报错 - 原因：ODBC 驱动将字符串参数识别为
ntext 类型，无法转换为 VECTOR - 解决：使用 T-SQL 局部变量
@embedding 中转
到入库这一步，查询的内容已经通过嵌入模型转换成向量序列了。具体如何转换会在下一篇做介绍。
相似度检索实现
使用 SQL Server VECTOR_SEARCH
关于如何检索，目前国内介绍的很少，在国外网站上能找到一些资源但都五花八门。这里我用了一个我自己已经调通的方式，就是基于SQL Server 2025 提供的原生的 VECTOR_SEARCH 函数，支持高效的向量相似度检索。
@staticmethod
def vector_search(query_embedding: List[float], top_k: int = 5, min_score: float = 0.0) -> List[dict]:
embedding_str = '[' + ','.join(str(x) for x in query_embedding) + ']'
sql = f"""
DECLARE @qv VECTOR(768) = CAST('{embedding_str}' AS VECTOR(768))
SELECT
tc.ChunkId,
tc.DocumentId,
tc.ChunkIndex,
tc.ChunkText,
tc.ChunkHash,
tc.CreatedAt,
d.Title,
vs.distance
FROM (
SELECT
*
FROM VECTOR_SEARCH(
TABLE = VectorIndex AS vi,
COLUMN = EmbeddingVector,
SIMILAR_TO = @qv,
METRIC = 'cosine',
TOP_N = {top_k}
) AS vs1
) AS vs
INNER JOIN TextChunks tc ON vs.ChunkId = tc.ChunkId
INNER JOIN Documents d ON tc.DocumentId = d.DocumentId
WHERE tc.IsDeleted = 0
ORDER BY vs.distance
"""
with vdb.get_cursor() as cursor:
cursor.execute(sql)
rows = cursor.fetchall()
results = []
for row in rows:
distance = row[7] if row[7] is not None else 1.0
score = 1.0 - distance
if score >= min_score:
results.append({
'chunk_id': row[0],
'document_id': row[1],
'chunk_index': row[2],
'chunk_text': row[3],
'chunk_hash': row[4],
'created_at': row[5],
'document_title': row[6],
'score': float(score)
})
return results
知识点笔记：
- VECTOR_SEARCH 语法：
VECTOR_SEARCH(
TABLE = table_name AS alias,
COLUMN = vector_column_name,
SIMILAR_TO = query_vector,
METRIC = 'cosine',
TOP_N = n
)
参数说明：
TABLE：指定向量索引表COLUMN：指定向量列（必须是 VECTOR 类型）SIMILAR_TO：查询向量（必须先转为 VECTOR 类型）METRIC：距离度量方式（'cosine'、'dot'、'euclidean'）TOP_N：返回前 N 个最相似的结果
为何使用 DECLARE 变量：
- 直接在
SIMILAR_TO 中使用 CAST('...' AS VECTOR) 会报错 - 使用
DECLARE @qv VECTOR(768) 声明变量后再引用可避免此问题 - 尚不清楚报错的原因
距离转相似度：
VECTOR_SEARCH 返回的是距离值（越接近 0 越相似）- 余弦相似度 = 1 - 余弦距离
为什么不直接去JOIN，而要套一层SELECT *。如果直接去JOIN，语法会报错说ChunkId有问题，尽管其在FROM VECTOR_SEARCH里确实是存在的，但就是找不到，所以这样折腾了一下。
阶段总结
经历N多轮报错，终于调通了一条能跑通的方式。现在社区资源关于这部分内容不是很多，所以解决起来确实花了点时间，而且有些问题看上去确实很挠头，只能根据自己的经验找办法去规避。确实相比其它技术方案，可参考的资料确实少了些，不过相信后续随着微软的推进，相关参考资料会逐渐丰富起来。
另，如果你用Vibe Coding生成SQLServer的相应代码，运行后大概率会出问题，可能当前（2026年5月）距离SQLServer 2025的发布（2025年11月前后），时间并不是很长，所以相应的代码库还没有更新，如果你在Vibe Coding中同样走不通，建议把此篇文章的URL提供给它作为参考。
也请留意如果在目前这个时间点你部署SQLServer 2025，并且使用Vibe Coding生成的话，大概率会给一套不用VECTOR字段和索引，用NVARCHAR(MAX)，然后在python代码里，把所有块都读过来，python代码里做余弦相似度计算。这个方法可行，适用数据量极小的场景，当然这在现实场景中是很难满足在数据量上的需求的，这是我在学习中踩过的坑，所以也是为什么会有这么一篇。当然随着社区内容的增多，Vibe Coding工具应该很快也会迭代知识库从而产出SQLServer 2025向量库原生支持的方法。
下一篇会继续介绍中间服务层和前端页面的构建，并且会把最终的整体代码都更细到Github上。
转自https://www.cnblogs.com/aspnetx/p/19976270
该文章在 2026/5/6 8:27:59 编辑过
400 186 1886
