当 BI 工具遇上 LLM：权限与成本的现实矛盾

企业引入 Text-to-SQL 技术时，常陷入两难：业务部门期待像使用自然语言 BI 工具般自由探索数据，而 DBA 团队看到的却是全表扫描风险。某电商平台在接入 DeepSeek-V4 实现自然语言查询后，曾因一个未限制的 "分析用户地域分布" 请求触发 200GB 临时表生成，直接拖垮分析型数据库集群。这种案例揭示了单纯依赖只读账号的局限性——权限控制只是第一道防线，真正的挑战在于预防性拦截和运行时熔断。

三级防护体系的设计要点

1. 静态权限隔离（必选基础层）

• 库级隔离：为 LLM 创建专属数据库账号，仅授予 SELECT 权限。实践中发现，MySQL 8.0+ 的 partial revoke 功能可精细到列级控制
• Schema 白名单：通过 search_path 限制可访问的 schema（如禁止 pg_catalog）。某金融机构采用动态 search_path 注入，根据用户部门自动限定数据范围
• 行级控制：利用 RLS（Row Level Security）实现租户数据隔离（需 PostgreSQL 9.5+）。注意 RLS 可能影响查询计划，建议配合 pg_qualstats 监控过滤条件有效性

-- 增强版 RLS 示例：结合 JWT 声明实现多维度过滤
CREATE POLICY multi_tenant_filter ON customer_data
    USING (tenant_id = current_setting('jwt.claims.tenant_id')::UUID 
           AND region_id = ANY(current_setting('jwt.claims.accessible_regions')::INT[]));

2. 动态拦截层（关键防御）

• 语法树分析拦截：推荐使用 pg_query_go 或 libpg_query 进行 SQL 解析，重点阻断：
• 多语句执行（实测显示 60% 的 SQL 注入尝试使用 ; 分隔）
• CTE 递归查询（曾导致某厂 32 核数据库 100% CPU 占用 6 小时）
• 未带 WHERE 的 3+ 表 JOIN（极易产生笛卡尔积）
• 资源预估模块：
• 基于 pg_stats 估算扫描行数（误差通常 <20%）
• 结合 pg_hint_plan 强制使用索引扫描
• 动态调整阈值：OLAP 场景可放宽至 50 万行，OLTP 严格限制 1 万行

3. 运行时熔断（最后防线）

• 强制超时：不同数据库配置方式：
• PostgreSQL：SET statement_timeout = '30s'
• MySQL：SET max_execution_time = 30000
• Oracle：ALTER SESSION SET resmgr_cpu_limit = 30
• 内存限制：Linux cgroup 需同时限制 memory 和 memory.swap
• 查询取消：监控 pg_stat_activity 时需注意 waiting 状态与 blocked_by 字段联动分析

DeepSeek-V4 的深度适配

提示词工程

1. 双重约束：在 system prompt 中同时声明 "你只能生成单条 SELECT 语句" 和 "禁止使用 WITH RECURSIVE"
2. 模式引导：提供数据库 schema 时，标注主外键关系（可降低 40% 的低效 JOIN）
3. 输出模板：强制要求返回格式为：

   # 分析结论
   {自然语言总结}
   
   # 执行SQL
   ```sql
   {单条SELECT语句}

   ```

校验流水线

1. 语法检查：用 pg_query_parse 验证 SQL 合法性
2. 模式验证：通过 pg_get_query_def 对比生成 SQL 与预期 schema 的兼容性
3. 成本预估：EXPLAIN (FORMAT JSON) 分析执行计划

成本监控与优化

实施路线图

1. 试点阶段（1-2周）：
2. 开放 <1GB 的维度表
3. 启用所有静态防护

4. 记录完整查询日志

5. 推广阶段（2-4周）：

6. 逐步开放事实表
7. 部署动态拦截规则

8. 建立基线性能指标

9. 成熟阶段（4周+）：

10. 实现自动索引建议
11. 动态调整查询阈值
12. 集成到 CI/CD 流水线

边界案例处理

• 模糊查询：LIKE '%keyword%' 必须限制前缀长度（如 LENGTH(keyword) < 20）
• JSON 解析：jsonb_path_query 需限制递归深度
• 地理查询：ST_DWithin 应约束最大距离参数

当遇到以下特征时，应触发人工审核流程： - 包含 GENERATE_SERIES 的时间范围查询 - 涉及 5 个以上表的 JOIN 操作 - 使用窗口函数且 PARTITION BY 列基数 >1000

替代方案评估

对于不适合 Text-to-SQL 的场景，建议考虑： - 预计算立方体：适合固定维度的聚合查询 - 物化视图：对高频复杂查询可提升 10-100 倍性能 - API 抽象层：对敏感数据提供受控的查询接口

最终决策应基于查询模式分析： - 临时探索式查询 → Text-to-SQL - 周期性固定报表 → 预计算 - 高频点查询 → API 抽象