把「帮我查个数」升级成专业工作流：表结构怎么给、需求怎么描述、拿到 SQL 之后还要问什么。
2026-09-04 · 约 7 分钟读完
让 AI 写 SQL 最常见的失败原因是信息不足。只说「查一下上周销量前十的商品」，AI 只能猜你的表结构：表名叫什么、字段有哪些、销量是订单表还是库存表。结果自然是写出一套「看起来对」的查询，跑起来全报错。
正确做法是用 SQL 模板时附上三样东西：相关表的建表语句（或字段清单）、几行真实样本数据、以及业务口径（「销量 = 已支付订单的商品件数，退款的不算」）。口径尤其重要——技术上的对错 AI 能判断，业务口径只有你能定义。
一个好用的句式：「用〈表 A〉和〈表 B〉，统计〈指标〉，筛选条件是〈时间 / 状态 / 范围〉，按〈维度〉分组，输出〈格式〉，数据量约 XX 万行」。数据量级一定要写，它决定了 AI 会不会给你在大表上做全表扫描的写法。
拿到 SQL 后不要直接跑，先让它「解释这条查询的执行思路，指出可能的性能问题」。AI 经常给出正确但低效的写法（比如在百万行表上用 NOT IN），让它自己审查一遍，通常能换来一个用索引、避免子查询的版本。生产环境跑之前，再用 EXPLAIN 看一眼执行计划——这一步 AI 替代不了你。
复杂查询拆成两步：先让 AI 写出中间结果的查询，确认数字对，再往上叠下一层。一步到位的嵌套三层查询，出了错很难定位。
SQL 只是取数，分析发生在取数之后。拿到结果后把数据贴回对话，追加两个问题：「这个结果里有什么异常值，可能的原因是什么」和「如果我想验证〈你的猜测〉，还需要查什么数据」。AI 在这一步的表现经常超出预期——它能提醒你漏掉的关键维度，比如季节性、渠道混杂或统计口径的变化。
当然要保持警惕：AI 对数据异常的解释是「合理假设」而不是「事实结论」，每个解释都需要你再用数据验证。把它当成一个思路活跃的分析师同事，它提假设，你做验证——这个分工才是不出错的。
注意每条示范里的三要素：表和字段、业务口径、数据量级。照这个规格喂料，你拿到的 SQL 一次能跑通的概率会高很多。
第一，别把敏感数据整表贴给 AI。给表结构、给字段说明、给脱敏后的样本数据（姓名换成张三李四、手机号换成假号段），足够 AI 写出正确的 SQL——它需要的是结构和口径，不是真实数据。用户隐私、订单明细这类数据一旦离开你的环境，就不在你控制范围里了。
第二，AI 写的 SQL 在生产库执行前必须自己审。重点看三处：UPDATE / DELETE 有没有 WHERE 条件、批量操作有没有 LIMIT 兜底、JOIN 有没有把表膨胀。让 AI 写、你来审、按流程执行，三条线各守各的。
养成分离习惯：分析类查询随便跑，任何写操作和数据导出都过一遍人工检查——这个习惯总有一天会救你。
接手别人的系统时，最头疼的往往不是写新 SQL，是读懂旧 SQL——三百行的存储过程、五层嵌套的视图。把 SQL 和相关表结构一起贴给代码解释模板，让它「逐段解释这条查询做了什么，最后指出性能隐患和逻辑上可疑的地方」，十分钟建立起对老代码的认知，比自己逐行啃快得多。
这个用法对排查历史数据问题同样有效：报表数字对不上时，把生成报表的 SQL 贴给 AI，让它检查业务口径（时间边界、去重逻辑、状态过滤）和你预期的差异。很多「数据不对」的悬案，最后都破在某个没人记得的过滤条件上。
你花功夫校准过口径的查询（「已支付口径」「剔除测试账号」「退款怎么算」），对同事来说同样有价值。让 AI 帮你把验证过的 SQL 整理成带注释的查询模板：「给这条 SQL 加上注释，说明每段的作用和业务口径，标出可替换的参数」。存进团队的查询文档，下次别人要做同类分析，改个时间范围就能用。
这个习惯的复利在团队层面：半年后新人入职，拿到的是一套口径清晰、验证过的查询模板库，而不是从头踩一遍口径的坑。AI 在其中的价值是把「个人经验」低成本地转化成「可复用文档」。
如果你刚开始接触数据分析，可以按这个顺序把 AI 用起来：先用对话直接分析小数据（学会提问和验证），再过渡到让 AI 写 SQL 取大数据（学会喂表结构和口径），最后进阶到让它协助解读复杂结果（学会提假设和证伪）。三步走完，你掌握的不只是「用 AI 分析数据」，而是一套「提问 → 取数 → 验证」的完整方法——这套方法在换任何工具时都成立。