范围：允许库表和时间窗
计划：扫描量与 Join 风险
运行：并发、时长与资源组
结果：行数、大小与导出
审计：用户、问题、查询与成本
结论：自然语言入口也必须遵守资源治理
“分析所有客户历史”可能生成大范围扫描或高基数 Join。即使查询只读，也可能影响数仓性能和费用。
把资源预算放在查询执行层，不能只依赖模型提示“尽量少查”。
执行前限制范围并估算风险
按项目和角色限制数据源、表、字段与默认时间窗；检查是否缺少分区过滤、是否存在笛卡尔积和大表全扫。
无法可靠估算时使用保守阈值或要求用户缩小范围。
运行中设置可取消的硬限制
设置超时、扫描量、内存、并发、结果行数和资源组。达到限制时终止查询并说明原因，不要自动反复重试。
高成本任务可转异步队列，但仍需配额、优先级和结果有效期。
用户体验要支持渐进分析
先返回汇总或样本，再让用户选择下钻；提示时间范围和维度为何昂贵，并给出可选缩小方式。
近似结果必须明确标记，不能与精确财务数字混用。
用压力和滥用场景验收
测试无时间条件、大表多 Join、高基数明细、多人并发、取消、超时和重试风暴，观察源库影响与审计记录。
AskTable.ai 可作为受治理问数候选；成本估算、数据库取消、队列和配额能力需按部署环境核验。
把自然语言问题转换成可量化预算
查询预算不应只有“超时 60 秒”一个阈值。可按项目定义允许扫描字节数、分区跨度、Join 表数、预计中间结果、并发槽位、内存、返回行数和导出大小，再按用户角色或工作负载分配日配额。计划阶段先估算，超过软阈值时要求缩小范围，超过硬阈值则拒绝执行；这样模型换代也不会绕过数据库层护栏。
预算还要与业务价值匹配。董事会月报允许排队几分钟，与门店收银高峰期的临时探索不是同一服务等级；财务精确核算也不能因成本高就自动改成采样。企业应为交互查询、异步分析、固定报告和批量导出分别设资源组、优先级和结果有效期。
在执行前检查查询计划和数据粒度
生成 SQL 后先做静态与计划检查：是否存在无分区条件的大表扫描、many-to-many Join、非选择性过滤、SELECT *、高基数排序、重复子查询或跨环境访问。若数据库支持 dry run、EXPLAIN 或扫描估算，应把预计成本与阈值比较；不支持时可依据表统计量和历史相似查询做保守估计。
粒度检查同样重要。订单头与订单行直接相连后再汇总客户金额，可能重复计算运费；把日快照与交易流水按日期范围 Join，可能产生平方级中间表。资源治理不能只看运行速度，还应阻止“运行得完但逻辑错误”的计划。高风险 Join 应回到语义模型中修复关系和聚合规则。
运行中必须可取消、可隔离、可解释
数据库连接要携带查询 ID、用户、项目和超时参数，使网关能在用户取消、页面离开或上游超时后真正终止底层任务。只在前端显示“已取消”而让仓库继续扫描，会制造隐性费用。并发控制应在队列入口实施，避免大量问题同时占满连接池；自动重试必须区分瞬时故障、资源超限和语义错误。
终止时给用户可执行解释，例如“当前问题覆盖三年明细并按客户排序，预计超过项目扫描预算；可改为最近 90 天汇总或先看前 20 个客户”。不要暴露内部敏感表名，也不要只返回模糊的系统繁忙。对于转异步的任务，应显示排队状态、取消入口、数据截止时间和结果到期时间。
用单位经济和容量实验设阈值
初始阈值可来自真实工作负载基线：记录每类问题的扫描量、延迟、失败率、并发和数据库费用，观察 P50、P95 与极端值，再结合业务重要性划分预算。阈值不是越低越好；过严会迫使用户拆成更多低效查询，过松则让少数探索占用全部资源。每次语义模型、索引或仓库规格变化后都要重新校准。
容量测试至少包含无日期过滤、跨三张大表、多用户同时追问、重复点击、页面取消、数据库限流和队列堆积。观察源系统 CPU、连接数、队列等待、取消生效时间和失败后的重试量。只有在压力下护栏仍位于执行层，而不是依赖模型自律，才能认为治理有效。
反例、验收指标与产品边界
反例包括：所有用户共享一个数据库账号，导致无法归责；只限制结果行数，却在返回前已扫描全表；超时后自动重试三次，实际放大资源消耗；用缓存返回旧结果，却不显示数据版本。验收应覆盖预算命中率、估算与实际偏差、取消成功率、队列等待、源库影响、单位问题成本和越权访问为零等指标。
AskTable.ai 可参与受治理问数方案评估，但本文不证明当前版本已经支持某一数据库的 dry run、工作负载隔离、成本回传或精确取消。需要在目标数据源上逐项核验生成查询、数据库账号、网关策略、缓存键、审计记录与异常降级；任何无法由执行层强制的限制，都不应写成已完成的安全能力。
一份最小查询预算策略示例
策略可分三层：普通交互默认最近 90 天、最多三表 Join、固定返回行数和短超时；分析员可申请更长窗口与异步队列；财务批量任务进入独立资源组并要求审批。每次执行记录 estimated_scan、actual_scan、queue_ms、run_ms、rows、cancelled_by、policy_version 和 cache_watermark。具体阈值必须用企业自身数仓基线确定，不能照搬文章中的示意层级。
验收负责人应同时查看用户成功率与平台保护效果：被预算阻止的问题是否给出可行缩小方式，取消是否真正传到数据库，缓存是否包含权限和水位，源库高峰期是否仍有资源余量。若大量正常问题被阻止，应优化语义模型、分区或预聚合，而不是简单放大上限；若少数查询长期占用资源，应修复计划或隔离工作负载。