AI时代，SQL该何去何从？

1.背景

前段时间，有个小伙伴问了我这样一个问题：辰哥，今天尝试了一下用cursor写sql，发现他完全可以替代SQL boy/girl，是这样吗，那俺练 SQL 还有啥意义？

确实，随着近几年来人工智能的爆发式增长，尤其是2025年下半年到现在，各种概念层出不穷，什么Agent、MCP、Skill等概念让人眼花缭乱，有同学难免会产生一些疑问：

AI都能写代码、做分析、自动调优了，我们还需要SQL吗？如果AI可以理解自然语言并自动生成SQL，那我们还用学SQL吗？

下面，我们就站在面试和实际应用等多个角度来讲讲，在如今的AI时代，到底还要不要学习SQL？如果需要的话，学习SQL时要更加注意什么？

2.在面试场景，AI 时代 SQL 可能的考察方向

先说结论：AI时代，SQL肯定还是要学的，而且要求更高！

随着AI大模型渗透到数据开发的全流程，数据工程师、数仓工程师、数据分析师的角色正在被重新定义。

过去那些"背几条SQL语法、懂几个窗口函数，做几个SQL题"就能过关的面试方式，可能已经无法筛选出真正适应未来的人才。

下面，给出一些在AI时代，除了去掌握SQL语法以及有解决问题的能力，还应该掌握哪些能力呢？

2.1 AI的应用能力

考察要点： 候选人是否真正将AI融入了日常数据工作，而不仅仅是听说过ChatGPT/豆包等，然后只会简单的对话交流...

过去，数据开发面试可能问"你用过哪些SQL优化工具？或者"你了解过哪些AI提效工具呢？"。现在，我们应该问："你是如何利用AI来提升数据开发效率和质量的？请用具体案例说明。"

当然，我们之前几期的AI分享中，也分享了很多AI工具在数据研发中的提效场景，几乎涵盖了整个数据研发工作的全流程之中，包括需求理解、数据探查、模型开发、任务测试、业务赋能、数据运营等等。

面试建议

掌握并理解具体案例，不要只是罗列工具。不能只说"我用AI写SQL"，而要多想想(提前准备一下这类问题，模拟一下)：当时遇到了什么复杂需求？你是如何设计提示词的？AI生成的SQL有什么坑？你是如何调试和验证的？
关注"AI + 数据开发"的典型场景： SQL编写与优化：例如，将一段复杂的业务逻辑描述给AI，让它生成SQL，然后你如何检查其正确性和性能？当AI生成的SQL执行缓慢时，你如何引导它优化？自动化数据管道/ETL：是否利用AI生成数据同步脚本、数据清洗逻辑？如何保证这些自动生成的代码符合团队规范？【也就是AI生成的逻辑，要和团队已有的规范对齐，如何实现？】数据质量与监控：有没有使用AI自动发现数据异常、生成数据质量规则？或者利用AI解读数据血缘，快速定位故障？数据文档与元数据管理：是否借助AI自动为数据表生成业务含义注释、编写数据字典？这能极大提升数据治理效率。

2.2 SQL的Review能力

考察要点： 在AI能代写大部分SQL的今天，候选人是否依然掌握SQL的本质------理解执行逻辑、识别问题、优化性能。

注意，这其实是一项很重要的能力，大家可以想象这样一个场景

你给了AI一大段提示词，AI一顿输出，生成了一段非常优雅的SQL逻辑，那你敢直接把AI生成的代码提交上线吗？

AI开发的代码是否符合业务预期？口径是否正确？是否有更优的解法呢，是不是会有性能或者数据倾斜风险？

这些东西，可能都需要人工进行判断。

因此，一个强大的阅读SQL的能力，Review-SQL的能力是非常重要的！这些能力也是靠阅读+练习大量的SQL练出来的。

【很多同学喜欢把自己写的代码抛给我，让我Review一下是否正确，但其实遇到自己不确定的SQL，是你锻炼SQL-Review能力的好机会！】

面试建议

未来的面试，SQL的考察可能不单单考察逻辑的实现，有可能会出现以下的考察场景：

面试官给你一段代码，让你解释一下这个代码是否可以解决某一道题目？
面试官给你两段类似的SQL代码，问你哪一个代码去解决当前问题是最优的？
面试官给你一段代码，让你指出其中可能存在的性能瓶颈（如数据倾斜、索引失效、关联顺序不当）。
面试官给你一段代码，让你提出优化建议，并说明理由（例如：是否应该改写为临时表、是否可以利用窗口函数替代自关联、是否应该调整分区裁剪）。
如果数据量级变化（从百万到百亿），原来的SQL会出什么问题？如何重构？
这才是考察的内容和实际应用的内容比较一致的！不会单独考察逻辑的实现，这也和我们wiki中专题十的内容相互对应。
当然，对于小白同学而言，还是要踏踏实实先把基础解题能力练好，再去慢慢拔高去适应现在AI时代的面试思路。

2.3 提示词能力

考察要点： 候选人是否具备清晰、结构化的提问能力，能否通过精准的提示词引导AI生成高质量、符合业务场景的数据解决方案。

没错，考察你的提示词能力如何？

很简单的场景，比如给你5min的时间，设计一段提示词，去解决特定的SQL问题或者让大模型生成一个新的模型。

你以为提示词那么好写？看看下面的内容把！

面试建议1： 提高提示词设计能力，要想的尽可能全面。

例如，面试官给定了一个业务需求（例如"计算连续7天登录的用户数"），让候选人写出他会如何向AI提问，并要求生成SQL。

举个例子(只是一个demo，实际开发要复杂的多)：

题目要求：已知表 user_login_table 有两个字段，分别是 user_id 和 dt(登录日期)，求有过连续7天登录的用户数。

小白提示词：

高手提示词：

或者，可以用AI给你写提示词(实际生产中)，你自己稍微根据具体情况修改一下：

|--------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------|
| | |

总结一下就是，在使用提示词时，对于一些相对复杂的需求，需要确认：

是否提供了表结构
是否明确了业务规则（如"连续"的定义）
是否指定了输出格式
是否考虑了边界条件

面试建议2：迭代优化能力。

如果AI第一次生成的SQL性能不佳，候选人能否通过追问（如"请使用窗口函数优化""考虑分区裁剪"）引导AI修正。

提示词能力本质上是结构化表达需求 与人机协作效率的体现，将成为数据开发者的核心软技能之一。

2.4 业务能力

考察要点： 数据开发最终要为业务服务，候选人需要证明自己懂业务、能沟通、能创造价值。

面试建议：

不要过分钻研技术，也不要过分强调技术，因为AI时代已经慢慢把个人技术壁垒击溃了，一个不懂前后端的人也可以用AI做出自己的产品。

而业务理解才是真正的护城河。

思考项目带来的业务影响。不要只想"你做了什么"，而要想"你做的这件事给业务带来了什么具体收益"。例如： "你优化的那个ETL任务，将计算时间从2小时缩短到10分钟，业务方因此能做什么之前做不了的事情？" "你搭建的数据平台上线后，分析师取数效率提升了多少？这相当于节省了多少人力成本？" "你设计的数据质量监控体系，曾经发现过哪些重大数据问题？避免了多大损失？"
考察与业务方沟通的场景。可以对自己提问："如果业务方拿着一个模糊的需求（比如'我要看用户活跃情况'），你怎么和他沟通，最终转化为清晰的数据需求？过程中你会考虑哪些维度？" 这考察的是候选人是否能挖掘真实需求，而不是被动接需求。
关注数据故事的讲述能力。当面对非技术背景的老板或客户时，候选人能否用通俗易懂的语言解释复杂的数据问题或技术方案？这是数据人员向上影响力的关键。

3.总结

回到开头那位小伙伴的疑问：AI都能写SQL了，我们还有必要学吗？

答案其实已经清晰了：不仅要学，而且要学得更深、更活、更贴近业务。

AI确实可以替代"SQL boy/girl"式的简单取数工作，但它无法替代的是你对业务的理解、对数据质量的把控、对复杂问题的拆解，以及在关键节点上的决策与判断。

未来的面试，不再只看你会不会写某个窗口函数，而是看你能否驾驭AI写出高质量的SQL，能否一眼看出AI生成代码的隐患，能否用精准的提示词让大模型成为你的得力助手，能否把技术成果翻译成业务价值。

这些能力，才是AI时代数据开发者的真正护城河。

所以，别担心AI会抢走你的饭碗------它只是把门槛提高了，把重复劳动省去了。你要做的，是把自己从"写SQL的人"升级为"懂数据、懂业务、懂AI"的复合型人才。这样，无论技术如何变迁，你都能稳稳地站在浪潮之巅。