【NL2SQL 实战 07】LIMIT 不是小事：默认 100 行背后的产品判断

上一篇讲「只允许 SELECT」做了三遍。评论区有人说：LIMIT 不就是补一行吗，有什么好写的？

LIMIT 本身确实是一行。但围绕这一行，产品判断、安全兜底、方言差异、运维可改、前端承受力，五件事交织在一起。 写错一个，要么用户抱怨「只给我看 100 条」，要么业务库和前端一起喘。

一、默认 100 不是拍脑袋（情境）

问数页面是对话式的。用户问「上个月各学校的跳绳人数」，期望看到一张能扫一眼的表格，不是一次导出三万行。

100 行是「够看、不炸」的平衡点：大部分 GROUP BY 查询维度不超过几十个，100 行覆盖常见粒度；前端表格组件渲染几百行还行，上万行开始卡；用户没写 LIMIT 时不补等于放全量，业务库扛不住。

关键产品判断： 100 存在系统参数表里，运维可以改。但默认值必须保守——新部署、没人配参数的时候，系统应该自我保护，而不是默默拖爆。

二、LIMIT 承担什么：四个环节的共同约束（任务）

LIMIT 不是一行 SQL 的事，它是数据库、应用层、前端渲染、网络推流四个环节的共同约束：

LIMIT 的目标不是「限制用户」，是让四个环节都不出问题。想放大，四个环节都得确认能扛。

三、怎么实现：三层配合（行动）

第一层：模型写大了，压回去。 模型有时候会写 LIMIT 10000——因为用户说了「给我全部」。闸门直接压回上限，不是提示用户「建议减少」。没写 LIMIT 就补，写了但合理就保留，写了 0 或负数就当没写补上。

产品判断：模型的 LIMIT 不等于用户的需求。 用户说「全部」，真正想看的可能是「不只 10 条」。真要导全量，走下载 / 报表，别走对话——对话是给人看的，不是给导数的。

第二层：探查工具更狠——封顶 10。 Agent 链路里的探查工具用来验证 JOIN 是否正确、字段取值分布长什么样，目的是「看一眼结构」不是「拉数据」。封顶 10 的原因：Agent loop 可能跑好几轮，每轮探查一次，拉多了上下文爆炸；探查是中间步骤用户看不到，浪费 token 和网络；探查如果不限，Agent 可能被注入问句诱导反复拉数据——10 行 + 步数上限双重封顶。

第三层：执行器兜底——多取一行检测溢出。 LIMIT 改写是 sqlglot 层面的，B4 讲过方言坑可能让 LIMIT 没生效。执行器不信任改写结果，取数据时多取一行——如果返回超过上限的行数，说明 LIMIT 没生效：

# backend/app/sql/executor.py（节选）
raw_rows = result.fetchmany(max_rows + 1)
if len(raw_rows) > max_rows:
    raise SqlGuardError("TOO_MANY_ROWS", f"结果超过 {max_rows} 行上限")

为什么是 max_rows + 1？不是为了多给一行，是为了检测溢出。为什么报错而不截断？因为截断比报错危险——用户看到不完整的数据但以为是完整的，报错至少让人知道「还有」。

两层 LIMIT 的关系： sqlglot 改写是让数据库少干活（SQL 层面），执行器兜底是让应用层不崩（应用层面）。两层抓的是同一个风险（拖爆），在不同层面兜。

四、谁能改、怎么改、改完怎么不炸（行动）

sql_max_rows 有三个来源，优先级从高到低：系统参数表（运维通过管理端改，热生效不用重启）、环境变量（部署时配，重启生效）、代码默认值（兜底）。

参数本身被夹在安全范围内（1～10000）——运维改成 0 或 99999，也会被夹回安全范围。

改完前端会不会炸？ 会，如果改太大。前端表格组件 100 行没压力，1000 行开始卡顿，5000 行以上可能白屏。更隐蔽的是 SSE 推流：用户等 10 秒看到 100 行能接受，等 30 秒看到 5000 行大概率会刷新页面。改大之前，先确认四个环节都扛得住。

五、几笔取舍，我现在还认（结果）

默认 100，不是 1000。 保守的默认值保护不懂配参数的部署者。想要更多行，显式改参数，别让默认放行。

压回去，不是警告。 模型写 LIMIT 10000 直接压到 100。对话场景不需要万行结果——不是限制用户，是保护用户（和业务库）。

报错，不截断。 截断意味着用户看到不完整的数据但以为是完整的。

探查 10 行，不可商量。 需要看更多是 Plan 层的问题——该拆查询，不该拉全量。

上限 10000，不是无限。 超过这个量级的导数需求，走报表 / 下载 / ETL，不走对话。

带走三句

• LIMIT 默认 100 是「够看、不炸」的平衡——数据库、应用层、前端、推流四个环节的共同约束；
• 模型写大了压回去，没写就补，执行器多取一行检测溢出——LIMIT 在两层做，抓的是同一个风险；
• 想改可以改（系统参数表热生效），但改完要确认前端扛得住。

开源仓库在下面，本地 Compose + Fixture 可以直接跑通，不需要先配云 API Key。说明看 docs/DEMO.md / AGENTS.md。

GitHub： https://github.com/yanqiuping110-cloud/xb-data-copilot-bot