生产数据库的一失足成千古恨
大模型在生成 SQL 时，很容易遗漏 WHERE 条件，或者在大表上执行未加索引的跨表慢查询，导致数据库 CPU 瞬间打满并引发线上雪崩。
必须部署的 5 道硬性技术防线
- 数据库层面的只读隔离：连接串必须配置仅有
SELECT权限的从库（Read Replica）独立账号，底层彻底禁止UPDATE/DELETE/ALTER； - SQL AST 语法树前置拦截：在请求发送给数据库前，通过 SQL Parser 检查语句类型，发现包含写操作立即拦截；
- 强制注入 LIMIT 约束：任何未显式带有 Limit 的查询，Proxy 自动在尾部追加
LIMIT 100； - 执行时间严格熔断：设置 3000ms 强制超时，超时立即执行
KILL QUERY； - 敏感字段动态替换：身份证、手机号、密码哈希字段在返回结果前由网关正则掩码。
第 5 道防线的脱敏规则完整设计可参考 数据安全与隐私合规：在企业内部推行 MCP 时的敏感信息（PII / Secret）脱敏实践。
落地步骤：只读链路从零搭起
- 在从库上创建仅供 Agent 使用的独立账号，权限收敛到
SELECT（如需诊断可加EXPLAIN），与人类工程师账号彻底分离； - 让 MCP Server 的连接指向一层 SQL Proxy，所有语句先经过解析器再转发；
- 在 Proxy 与数据库两侧同时设置语句超时，避免只依赖任何单侧；
- 配置连接池上限与空闲回收，再为敏感字段建立脱敏白名单表；
- 上线前用红队用例回放一遍（见下文验证方法），全部通过后才开放给业务团队。
参数建议基线（经验值）
| 参数 | 建议起点 | 说明 |
|---|---|---|
| 单查询行数上限 | LIMIT 100 | 可放宽但必须有硬上限 |
| 语句超时 | 3000ms | 超时立即终止，不给"再等等"的机会 |
| 连接池最大连接 | 个位数起步 | AI 请求突发性强，宁可排队不可压垮数据库 |
| 单会话查询次数 | 10~20 次后提示收敛 | 防止模型陷入循环探测拖高负载 |
以上数值应结合实例规格压测后调整，核心原则是：任何一项参数都必须存在，而不是取值精妙。本地实验环境的具体接法可以先照 Claude Desktop 接入本地 SQLite 与 Filesystem 实战：打造私有数据分析工作台 练手。
验证方法：红队用例清单
- 让模型生成并执行一条不带
WHERE的更新语句，确认在第 1、2 道防线任一环节被拒； - 在大表上触发一次全表扫描，确认 3 秒内被熔断且数据库负载曲线迅速回落；
- 查询含手机号字段的表，确认返回值已掩码且掩码不影响行数与列名；
- 统计一周内被拦截语句的分布，作为调整白名单与阈值的依据。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 查到的数据明显滞后 | 从库存在复制延迟 | 在工具描述中声明数据新鲜度，关键统计走审计通道 |
| 连接数周期性飙升 | 定时 Agent 任务长时间占用连接 | 收紧连接池并为批量任务限并发 |
| 合法查询被拦截器误杀 | AST 规则未覆盖少见语法 | 建立拦截日志复核机制，按周补充白名单 |
| 掩码后的结果被拼回明文 | 只掩码出口、日志里仍是原始行 | 对审计日志与缓存介质同步脱敏 |
小结
检验标准只有一条：把一条模型可能生成的最坏 SQL 放进链路，它是否仍然伤不到生产库。五道防线是纵深设计，任何单独一道被绕过时后面必须还有兜底；如果目前只有"提示词里叮嘱模型别写 UPDATE"这一道心理防线，等于没有防线。