Azure SQL | The .NET Blog

NL2SQL 是智能体时代的 SQL 注入

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

NL2SQL 有一个听起来很完美的推介版本：用户用自然语言提问，智能体生成 SQL，数据返回。更少的界面，更少的查询，更少的代码。简单。

然后你再多想五分钟。

演示中没人提的问题

模式（Schema）不是为了解释事物而设计的。 晦涩的表名、不一致的列名、在没有额外谓词的情况下语义上无效的技术有效关系——这在企业数据库中很常见。这些不是 bug，只是业务变更积累的历史。但当你要求模型从一个并非为传达意图而设计的模式中推断意图时，模型还是会尝试。它不会放弃。它会生成最佳查询并自信地返回结果。

模型是非确定性的。 对同一个数据库问同一个问题两次，你可能会得到不同的 SQL。模型在计算概率，上下文中的细微变化会产生不同的输出。你无法通过测试获得智能体总是生成正确查询的保证。

用户审查无法扩展。 “执行前只需审查每个查询"听起来很安全。但这假设用户既是数据模型又是 SQL 的专家——恰恰是那些不需要自然语言界面的人。它还引入了认知过载和新型确认偏差，被查询复杂性压倒的用户会批准无效查询而不是去调查它们。

然后还有注入。 在传统 SQL 开发中，参数化解决了注入问题，因为用户输入填充的是参数，而不是 SQL 结构。在 NL2SQL 中，模型本身生成 SQL。提示词、模式上下文、对话历史和检索的数据都会影响执行的内容。如果有人精心设计一个改变模型生成内容的提示，那就是注入——不是在参数级别，而是在查询生成级别。与 DROP TABLE（明显、可恢复）不同，NL2SQL 注入会产生在没有可见错误的情况下返回错误结果的查询。业务决策基于错误数据做出。

SQL MCP Server 究竟解决了什么

这里文章提出了最有用的实用观点。SQL MPC Server 不是给智能体任意的模式访问权限并期待最好的结果，而是暴露了一个建立在 Data API builder 之上的精心策划的 API 表面。

差异很重要：智能体不生成 SQL。它调用返回预定义结果形状的命名端点。SQL 由开发人员编写一次，是确定性的。智能体的非确定性被限制在选择调用哪个端点，而不是组合任意查询。

这类似于参数化在传统应用模型中对 SQL 注入所做的——消除了从不受信任的输入构建任意查询的能力。

正确的问题

这篇文章不是说"永远不要使用 NL2SQL”。它说：对在哪里应用它以及暴露什么要有意识。对于在受控环境中、具有有限范围模式和只读访问权限的探索性分析，NL2SQL 可能没问题。对于业务决策依赖于结果的生产系统，经过精心策划的 API 层要安全得多。

说实话：有些问题确实更适合用命名端点后面的结构化查询来解决，而不是自然语言到 SQL。SQL MCP Server 为你提供了这个选项，而不必完全放弃智能体界面。

原文链接：Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL 现在可以生成嵌入向量了 — 纯 T-SQL，无需应用层

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

如果你曾经构建过 RAG 管道，你就知道管道税：你的数据存在于 SQL 中，但要生成嵌入向量，你需要提取数据、调用嵌入 API、处理批处理和速率限制，并将结果存储到支持向量搜索的地方。通常是在完全不同的数据库中。

Azure SQL 刚刚通过两个现已正式发布的功能消除了大部分这些问题：CREATE EXTERNAL MODEL 和 AI_GENERATE_EMBEDDINGS。

它们的作用

这两个 T-SQL 功能作为集成管道工作：

CREATE EXTERNAL MODEL — 将外部 AI 模型端点注册为命名数据库对象。你只需设置一次位置、API 格式、模型类型和凭据。随处可重用。

AI_GENERATE_EMBEDDINGS — 一个标量 T-SQL 函数，调用注册的模型并返回向量值的 JSON 数组。可在 SELECT、INSERT、UPDATE 和 MERGE 语句中使用。

它们共同形成端到端的嵌入管道，无需离开 SQL 引擎。

完整工作流程

-- 步骤 1：一次性注册嵌入提供程序
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- 步骤 2：在 T-SQL 中内联生成嵌入
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- 步骤 3：用向量距离搜索
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

这就是整个管道：SQL 中的数据、SQL 中生成的嵌入、SQL 中的相似性搜索。没有编排层，没有 ETL，没有单独的向量数据库。

支持的 API 格式和选项

正式发布时，API_FORMAT 支持 Azure OpenAI 和 OpenAI。MODEL_TYPE 目前固定为 EMBEDDINGS。PARAMETERS JSON 允许设置模型级别的默认值，包括重试次数：

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

身份验证使用数据库凭据，因此密钥保留在应用程序代码之外。

这为 .NET 应用程序带来了什么

对于在现有 SQL 数据上构建 AI 功能的 .NET 开发者来说，这意义重大。你不需要：

为嵌入将数据提取到中间存储
管理外部嵌入管道
设置单独的向量数据库（如果你想要全功能的向量存储，可以使用 Azure AI Search）
更改应用程序的数据访问层

你可以使用已有的相同 T-SQL 工具，逐步向现有 SQL 应用程序添加语义搜索。

总结

SQL 数据上的 RAG 模式变得简单多了。AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL 意味着你现有的 SQL 应用程序可以在不添加新基础设施的情况下获得向量搜索功能。

这两个功能今天在 Azure SQL Database 和 Azure SQL Managed Instance 中已正式发布。

原始帖子：Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio 已停用：将您的 Azure SQL 工作流迁移到 VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处.

Azure Data Studio 于 2025 年 2 月 6 日停用，支持将于 2026 年 2 月 28 日结束——推荐的替代方案是带有 MSSQL 扩展的 VS Code。

需要安装的内容

开始所需的三样东西：

MSSQL 扩展 — 在 VS Code Marketplace 中搜索"SQL Server (mssql)"
SQL Database Projects 扩展 — 模式即代码、构建验证、引导式发布
.NET 8 SDK — 构建系统所需；SDK 缺失是首次运行时最常见的问题

迁移 ADS 连接和设置

MSSQL 扩展附带 ADS Migration Toolkit，在引导式流程中处理一次性迁移：已保存的连接、连接组、设置和键绑定均自动导入。

恢复 F5 肌肉记忆

ADS 用户依靠 F5 运行查询。安装 MSSQL Database Management Keymap 扩展，即可恢复 ADS 风格的键绑定，包括 F5。

SQL Database Projects：模式即代码

右键单击项目 → 发布 → 配置目标 → 审查生成的 T-SQL 脚本 → 部署。部署前的脚本预览是关键安全功能。项目模板为表、存储过程和视图生成存根——与 SSDT 相同的工作流。

常见问题：如果项目是针对不同的 SQL Server 版本创建的，.sqlproj 文件中的目标平台不匹配将导致构建错误。

Schema Compare 和 Schema Designer

该扩展还包括 Schema Compare（对比项目与已部署数据库的差异）和 Schema Designer（无需手动编写 DDL 即可进行可视化架构编辑）。

Microsoft Fabric 开发者

设置相同，但请先从 Fabric 门户开始，先将数据库连接到 Git，再在 VS Code 中打开。Microsoft 有专门的指南：Azure Data Studio to VS Code — What it means for SQL database in Fabric developers。

总结

迁移是一次性的引导式流程，而非手动重建。安装三个工具，运行 ADS Migration Toolkit，恢复键绑定，即可在 10 分钟内恢复正常。

请参阅完整文章，获取逐步截图和 Fabric 专属演练。

SQL MCP Server 在 Azure App Service 上运行 — 无需容器

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处。

老实说：每次在教程中看到"需要容器"，我内心都会叹一口气。容器很棒——直到你的团队没有容器策略，一个看似简单的功能突然被意料之外的编排复杂性阻挡。

这就是为什么这个让我眼前一亮。SQL MCP Server 现在可以在 Azure App Service 上运行——无需 Docker，无需 Kubernetes，只需相同的 Data API Builder（DAB）配置文件，通过 MCP、REST 和 GraphQL 公开你的 SQL 数据库。

什么是 SQL MCP Server？

如果你还不了解，简单介绍一下。SQL MCP Server 位于你的 AI 代理和 SQL 数据库之间。它不是让代理直接访问数据库（这是个糟糕的想法），而是将你的表和视图作为带有定义权限的实体抽象层公开。

它构建在 Data API Builder 之上，这意味着单个配置文件同时管理 MCP、REST 和 GraphQL。你的代理与 MCP 端点通信，传统应用与 REST 或 GraphQL 通信。相同的配置，相同的运行时，不同的接口。

这真的很有用——你不需要维护两个独立的 API 层。

容器问题（及解决方案）

SQL MCP Server 最初的部署模型是容器。这在很多团队中运行良好，但并非所有团队都适用。许多 .NET 团队标准化使用 Azure App Service 或虚拟机。仅仅为了公开 SQL 端点而需要容器运行时，增加了没有人要求的摩擦。

新的教程展示了如何完全跳过容器。一切都通过 dab start 命令运行，作为标准的 .NET 8 Web 进程托管在 App Service 上。

# 安装 Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# 初始化配置
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# 添加实体
dab add products --source dbo.products --permissions "authenticated:*"

# 配置 App Service 认证提供程序
dab configure --runtime.host.authentication.provider AppService

# 启动服务器
dab start

此时，你在 /mcp 有 MCP，同一进程提供 REST 和 GraphQL，没有任何东西运行在容器中。

无需共享 API 密钥的身份验证

这是我最欣赏的部分。部署到 App Service 时，你将 Microsoft Entra ID 配置为身份验证提供程序。配置文件中没有共享密钥，不需要轮换 API 密钥。

连接字符串保留在 App Service 环境变量中（不在 dab-config.json 中），MCP 端点通过平台身份验证保护。如果你的 Azure 工作负载已经与 Entra ID 对齐，这将自然融入。

本地开发时，切换到 Simulator 模式和 STDIO 传输。部署前切换回 AppService 模式。干净且明确。

部署到 App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

然后使用你的团队已经使用的代码部署方法部署你的 DAB 项目。关键细节：这是代码部署，不是容器部署。

为什么这对 .NET 开发者很重要

如果你在 .NET 中构建 AI 代理，你的代理最终需要与数据库通信。SQL MCP Server 提供了一种结构化的方式来实现这一点，无需暴露原始连接字符串。

查看原始博客文章和 GitHub 示例仓库的完整教程。

总结

App Service 上的 SQL MCP Server 是 .NET 团队的实用选择，无需容器策略即可为代理提供结构化的 SQL 数据访问。试试看——你的代理会很感激清晰的 API 接口。

SQL Server 2025作为代理就绪数据库：一个引擎中的安全、备份和MCP

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击这里。

我一直饶有兴趣地关注Aditya Badramraju的Polyglot Tax系列。第4部分用实际决定你是否会在生产环境中信任这种架构的部分来结束系列。

所有数据模型的单一安全模型

一个行级安全策略覆盖所有数据模型。对审计员来说，一个策略，一个证明。

统一备份 = 原子恢复

在多语言堆栈中，跨五个数据库的时间点恢复是一场一致性噩梦。只有一个数据库时，恢复在定义上就是原子的。

MCP集成：无需手动编写中间件

SQL Server 2025直接支持SQL MCP服务器。代理调用工具，引擎自动强制租户隔离和列掩码。

原始文章（Aditya Badramraju著）：The Polyglot Tax – Part 4。

SQL MCP Server — 给 AI 代理数据库访问的正确方式

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

说实话：今天市面上大多数数据库 MCP 服务器都很可怕。它们接受自然语言查询，即时生成 SQL，然后在你的生产数据上执行。有什么可能出错的？（一切。一切都可能出错。）

Azure SQL 团队刚刚发布了 SQL MCP Server，它采用了一种根本不同的方法。作为 Data API builder（DAB）2.0 的功能构建，它为 AI 代理提供结构化、确定性的数据库操作访问 — 没有 NL2SQL，不暴露你的架构，每一步都有完整的 RBAC。

为什么不用 NL2SQL？

这是最有趣的设计决策。模型不是确定性的，复杂查询最容易产生微妙的错误。用户希望 AI 能生成的那些查询，恰恰也是在非确定性生成时最需要审查的查询。

相反，SQL MCP Server 使用 NL2DAB 方法。代理使用 Data API builder 的实体抽象层和内置查询构建器来确定性地生成准确、格式良好的 T-SQL。对用户来说结果相同，但没有幻觉 JOIN 或意外数据泄露的风险。

七个工具，不是七百个

SQL MCP Server 精确暴露七个 DML 工具，与数据库大小无关：

describe_entities — 发现可用实体和操作
create_record — 插入行
read_records — 查询表和视图
update_record — 修改行
delete_record — 删除行
execute_entity — 运行存储过程
aggregate_records — 聚合查询

这很聪明，因为上下文窗口是代理的思考空间。用数百个工具定义淹没它们会减少推理空间。七个固定工具让代理专注于思考而不是导航。

每个工具可以单独启用或禁用：

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

三条命令开始

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

这就是一个运行中的 SQL MCP Server，暴露你的 Customers 表。实体抽象层意味着你可以为名称和列创建别名、按角色限制字段，并精确控制代理看到的内容 — 而不暴露内部架构细节。

安全故事很扎实

这是 Data API builder 成熟度发挥价值的地方：

每一层都有 RBAC — 每个实体定义哪些角色可以读取、创建、更新或删除，以及哪些字段可见
Azure Key Vault 集成 — 安全管理连接字符串和密钥
Microsoft Entra + 自定义 OAuth — 生产级认证
内容安全策略 — 代理通过受控契约交互，而不是原始 SQL

架构抽象特别重要。你的内部表名和列名永远不会暴露给代理。你定义对 AI 交互有意义的实体、别名和描述 — 而不是你的数据库 ERD 图。

多数据库和多协议

SQL MCP Server 支持 Microsoft SQL、PostgreSQL、Azure Cosmos DB 和 MySQL。由于它是 DAB 的功能，你可以从同一配置同时获取 REST、GraphQL 和 MCP 端点。相同的实体定义、相同的 RBAC 规则、相同的安全性 — 跨所有三种协议。

DAB 2.0 的自动配置甚至可以检查你的数据库并动态构建配置，如果你愿意为快速原型设计减少抽象的话。

我的看法

这就是 AI 代理的企业级数据库访问应该如何工作。不是"嘿 LLM，给我写点 SQL 然后对生产环境 YOLO"。而是：定义良好的实体层、确定性查询生成、每一步的 RBAC、缓存、监控和遥测。以最好的方式无聊着。

对于 .NET 开发者，集成故事很清晰 — DAB 是 .NET 工具，MCP Server 作为容器运行，与大多数人已经在用的 Azure SQL 配合工作。如果你正在构建需要数据访问的 AI 代理，从这里开始。

总结

SQL MCP Server 是免费、开源的，可在任何地方运行。这是微软为给 AI 代理提供安全数据库访问的规范性方法。查看完整文章和文档开始使用。