AI 已经会写 SQL为什么连接数据库还需要 MCP因为会生成 SQL只解决了表达问题。AI 还要发现数据库工具、传递参数、拿回结果并且每一步都受到权限约束。真正难的不是让 AI 查到数据而是让它以可控的方式查到数据。这篇文章沿着一条真实查询的链路讲清 MCP、数据库驱动、SQL 和安全边界各自负责什么最后给出生产上线前需要补齐的控制清单。不涉及具体数据库产品的推销只讲协议和权限本身。先回答一个问题AI 会写 SQL为什么还需要 MCP没有 MCP 之前每个 AI 应用要自己定义工具名称、参数格式、鉴权方式、连接代码和结果结构。换一个模型、编辑器或数据源往往又要写一套适配。真正重复的不是 SQL 本身而是工具集成层。MCPModel Context Protocol要解决的就是这一层让 AI 应用与外部工具、数据源之间的交互有一套标准。官方定义很直接——MCP 只关注上下文交换的协议不规定 AI 应用如何用大模型也不负责管理上下文。MCP 是什么协议不是USB 接口常有人说MCP 像 AI 世界的 USB 接口。这个比喻适合入门但不完整。USB 是硬件接口规定了物理层和传输层MCP 是应用层协议定义 AI 应用与外部上下文、工具之间的交互方式。MCP 负责发现和调用能力但它不规定模型怎样推理不替代数据库自己的连接协议更不是安全产品。一个容易踩的误区把 MCP 当成数据库连接器。MCP Server 内部怎么访问数据库由 Server 自己实现——它可以用 JDBC、用 psycopg2、用任何驱动协议不管这部分。一次调用里的三个角色Host、Client、Server一次 MCP 调用有三个参与方职责各不同角色是什么负责什么Host承载模型和对话的 AI 应用Claude Desktop、VS Code 等协调多个 Client向模型提供上下文ClientHost 内为每个 Server 建立的一个连接组件维护与 Server 的协议通信Server暴露能力的一方提供工具Tools、资源Resources、提示模板Prompts连接真正的业务系统注意两点一个 Server 对应一个 Client。Host 连接多少个 Server就实例化多少个 Client。Server 是提供上下文的一方不管它跑在本地还是远端。容易混淆的四个概念MCP、Function Calling、RAG、数据库驱动这四者经常被混着说实际上处在完全不同的层次概念一句话定义层次Function Calling模型输出工具名 参数的能力模型能力层MCP客户端统一发现、调用外部 Server 工具的标准协议协议/集成层RAG先检索资料、再让模型生成答案的应用模式应用模式层数据库驱动建立连接、发送 SQL、处理事务、读取结果数据访问层它们不是竞争关系而是可以出现在同一条调用链上模型用 Function Calling 表达调用意图 → 客户端通过 MCP 找到并调用工具 → Server 内部用数据库驱动执行 SQL → 检索类工具则可以通过 MCP 暴露给 RAG 应用使用。一次真实查询走完整条链路用一条查询贯穿全过程查询上个月门诊的医保结算总额。用户问题自然语言① 工具发现列出 query_settlement_summary 及参数说明② 参数生成转为 科室 / 起止日期 / 结算类型③ 工具调用Client 发起Server 校验参数和身份④ SQL 执行数据库驱动跑参数化 SQL⑤ 结果返回模型解释数字、生成回答第 ④ 步是整个链路的安全关键。看一段对比sqlfSELECT SUM(settled_amount) FROM settlement WHERE dept_name{dept} AND settle_date BETWEEN {start} AND {end} AND visit_type{vtype}cur.execute(sql)# 正确参数化 SQL参数与语句分离sqlSELECT SUM(settled_amount) FROM settlement WHERE dept_name%s AND settle_date BETWEEN %s AND %s AND visit_type%scur.execute(sql,(dept,start,end,vtype))参数化不只防注入它强制数据和指令分离。配合用途明确的业务工具query_settlement_summary比暴露一个万能 execute SQL 工具多了一层明确的业务边界。为什么只读账号仍然不够“给 AI 一个只读账号不就行了”——不行。只读只能阻止写入挡不住下面这些全表扫描与资源滥用一条SELECT *就能拖慢生产库只读权限管不了查询成本。越权读取模型可能生成完全合法的 SQL却查到了当前用户不该看的租户数据。多租户场景下这等于横向越权。间接提示词注入数据库里的文本内容本身可能夹带指令诱导 Agent 去调用其他高权限工具。OWASP 将其列为 LLM 应用头号风险LLM01:2025。结果泄露敏感字段、超大返回集只要读得到就会泄露。无限重试与不可追踪没有审计你甚至不知道是谁、在什么时候、用哪条 SQL 拿走了数据。所以危险的不只是错误 SQL而是整个自动调用链拥有了过大的能力。生产上线前要补齐的六层控制把上面的风险收拢成可执行清单上线前逐项过1. 工具边界不优先提供万能 SQL 工具。提供用途明确、参数受限的业务工具比如 query_settlement_summary而不是 execute_sql。2. 数据库权限最小权限只授权必要的视图不授整库。多租户场景启用行级安全Row Level Security按角色和命令限制可见行。注意一个坑表所有者和带 BYPASSRLS 的角色通常可以绕过 RLS生产配置需要单独核查。3. 参数校验在 Server 端做校验schema 白名单、行数上限、敏感字段脱敏、参数类型和取值范围。4. 资源上限查询超时、锁等待上限、并发上限、单次任务预算。防止一次失控查询拖垮整个实例。5. 人工审批写入、删除和高风险查询必须有人工确认或独立审批环节。这是 OWASP 明确建议的 human-in-the-loop 控制。6. 全程审计记录每次工具发现、调用参数、SQL 摘要、结果规模和操作者。出了事要能回溯到具体某一次调用。这六层对应 OWASP LLM01 的缓解建议约束模型行为、最小权限、输出过滤、人工审批高风险动作、隔离外部内容。常见问题QMCP 是数据库连接池吗不是。MCP 是协议管的是AI 应用怎么发现和调用工具连接池是 Server 内部实现细节协议不关心。Q有了参数化 SQL还需要权限控制吗需要。参数化解决的是 SQL 注入解决不了越权、全表扫描和敏感字段泄露。两层是叠加关系不是替代关系。QRAG 能替代 MCP 吗不能。RAG 是检索后生成的应用模式MCP 是工具调用的标准协议。RAG 的检索工具完全可以挂在 MCP Server 后面两者各管一段。Q只读账号 行级安全就够了接近了但还差两层资源上限防拖垮生产库和审计出事能回溯。工程上建议六层一起过。总结MCP 标准化的是工具发现和调用方式让同一个数据库能力可以被不同 AI 应用复用它不保证 SQL 正确、不保证权限最小、也不保证查询便宜真正成熟的方案不是给 AI 更多权限而是让每一次能力调用可描述、可限制、可追踪。行动建议如果你正在给 Agent 接数据库先做两件事——把万能 SQL 工具换成参数受限的业务工具给专用账号配最小权限并启用审计。剩下的四层控制按风险优先级逐步补齐。参考MCP 官方架构文档、MCP 工具规范、PostgreSQL 用户管理/行级安全文档、OWASP LLM01 提示词注入。