DeepSeek：数据工程师怎么用？SQL 与管道

数据工程师的日常里，有两段时间最容易被吃掉：写一段口径复杂的 SQL，和查一条管道为什么没跑出预期结果。DeepSeek 在这两件事上都能省时间，但省的是打字和试错的时间，不是判断的时间。口径对不对、结果能不能信，仍然要你自己拍板。

SQL 的口径比写法更容易错

一段 SQL 写完跑得通，不代表结果对。错得较多的地方是口径：时间范围按自然日还是按滚动窗口、主体范围含不含测试账号、去重是按用户还是按订单。这三件事工具不知道，你不说，它就按通行做法猜，猜出来的结果和报表对不上。

所以提问时先把口径写成三句话：算什么人、算哪段时间、一个人算几次。这三句写清楚，SQL 的结构基本就定了。写不清楚，说明需求本身还没对齐，这时候让工具写代码只会把模糊放大。

拿到 SQL 后看两处：关联条件和聚合维度。关联条件错，行数会翻倍或者塌陷；聚合维度错，总数对但明细不对。这两种错误都不会报错，只能靠对账发现。

把表结构给全，比把需求说漂亮有用

模型看不到你的库，它只知道你贴给它的东西。建表语句、字段注释、枚举值含义、分区字段、大致行数，这几样给全，写出来的 SQL 才可能是可执行的。只给一句「用户表和订单表」，它只能编字段名。

行数这件事值得单独说。一张上亿行的表和一张十万行的表，写法不一样：前者要考虑分区裁剪和预聚合，后者怎么写都能跑。你告诉它量级，它才会提示你哪里可能慢。

需要多步推理的任务再开深度思考更划算：口径拆解、执行计划分析这类要权衡的活适合开；改个字段名、补个过滤条件不用开，开了反而慢。

性能问题看三个信号

执行计划里先看扫描行数，再看有没有走分区，末了看 join 两侧的数据量分布。扫描行数远大于结果行数，说明过滤没推到前面；分区没裁剪，说明条件写在了函数里；join 两侧量级差几个数量级，可能有倾斜。

模型能指出可能的瓶颈，但它看不到真实的数据分布。统计信息过期、热点键、空值占比这些，只有查过实际数据才知道。它说「这里可能慢」，你要用执行计划去验证，不能直接照改。

这张表的用法是倒着看：先确认现象落在哪一行，再按「先查什么」那一列走，能跳过一半的无效排查。

排查从数据往回倒，不从代码往下读

管道出问题，直觉是读代码。代码几百行，读一遍半小时，还不一定看出问题。更快的路径是从结果往回倒：目标表某个分区为空，就看中间表同分区有没有数据；中间表有，问题在末步；中间表没有，再往上看源表。

每一层做一次行数校验，范围就缩小一半。定位到具体一段之后，再把那段逻辑和数据样本交给模型，让它列出可能的原因。带着范围问，比丢一整条链路问，命中率高得多。

校验要有基线。今天的结果和上周同一天比、和上游源表比、和已有报表比，三个对比做完，异常点会自己冒出来。没有基线的时候，先跑一次全量对账，把基线建起来。

它做不到的部分

它不知道你们公司「活跃用户」怎么定义，也不知道哪张表已经废弃、哪个字段是新加的。这些存在文档、群聊和老人脑子里，模型一概不知。你不给，它就用行业通行定义，而通行定义往往和你们的口径差一点，差的这一点足够让结论反过来。

它也可能写出语法正确、语义错误的 SQL。窗口函数的边界、空值的处理、除零的保护，这些细节很容易被忽略，而它们在数据里造成的偏差不会立刻显现。生成的 SQL 一律当草稿，跑之前先在小样本上验证。

它连不上你的生产库，也看不到执行计划。真实的行数、倾斜、锁等待，都要你自己查。

用前用后各三件事

• 用前：写清算谁、算哪段、算几次
• 用前：给全建表语句、枚举含义、数据量级
• 用后：核对关联条件与聚合维度
• 用后：与既有报表对账，差异先查再说
• 用后：敏感字段用脱敏样本调试

团队怎么把经验留下来

单次问答的价值有限，沉淀下来的才有复利。三样东西值得建：口径字典（每个指标怎么算、谁定的）、表说明（哪些表能用、哪些已废弃）、排查记录（某类现象通常是什么原因）。前两样给模型当上下文，后一样给自己查。

口径字典可以放进共享知识库，让组内所有人都能问同一份资料。共享知识库的搭法讲的就是怎么组织这类资料；提示词也一样，把建表规范、命名习惯写进固定模板，从通用模板改成项目专用，比每次重新描述省事。任务多了以后，把历史会话检索出来复用也能少走弯路。

几个常被追问的点

• 能不能把库连上去让它自己查？：多数对话产品不直接连生产库。可行的做法是你本地查好样本再贴进去，或者用脱敏后的导出行。直接连生产库的风险不在技术，在权限。
• 窗口函数总写不对怎么办？：先让它用文字描述「按什么分组、按什么排序、取第几行」，确认逻辑对了再要代码。直接要代码，错了你也不知道错在哪一层。
• 数据倾斜它看不出来吗？：看不出来。倾斜要基于真实分布判断，模型只能提醒你「这里可能倾斜」。查法是按 join 的键分组计数，看前几个值占了多少比例。