全栈工作两年，面试基础的 SQL 都没写出来，为什么

工作是工作，面试是面试。面试得复习的。

候选人太多了，其他人能写出来。

还是写的少了呗，不然咋样，说你还不够“全栈（全干）”？

至少我认为的全栈：
老大你给我配个前端啊，不能天天让我凑合着写这玩意啊，我又不熟，说好了啊，我先弄着，下个月，下个月一定给我一个前端
你到是给我个 DBA 啊，啥叫自己优化，我业务都来不及做，数据库你找个专职的弄啊，说好了啊，等人到位这活儿高低不能我继续干了
不是，老大啊，运维离职了你抓紧招新的啊，天天让我顶着不是个事儿啊，这马上年底了业务我都做不过来了啊
咋又让我去装系统，软件弄弄半天就过去了我东西还没做完呢啊，他们不会你让他们做几次就懂了啊

我只会 select * from table; 插入和更新都要查

说实话我觉得挺正常，工作都是 orm ，gui 工具还有 tab 补全

如果是基础的语句那确实不应该哈，如果是复杂的那纯粹就是供大于求，只能搞一些规则来筛选人。
哪怕 T10 日常工作中也会犯小错误，太正常了。
最后，日常工作中 ORM 真的很方便。遇到过用原生 SQL 的项目，太傻逼了，难写、容易出错、难以维护、代码变丑。

我也已经不会写 SQL 了

现在工作都是面试严格，工作简单。

命运它并不公平，有时候没能力的人入职了，能做事的人却被拒绝

不过兄弟你看看你正文的字，它们读着通顺吗？

https://s2.loli.net/2025/10/17/6RqSifhrbZgayl4.png

@newaccount 确实是比较菜，然后现在都是依赖 Ai 混日子

以后会越来越多的，AI 后，人会越来越懒

关键词顺序…where group by order by having 这些？就算常写的都是靠 IDE 提示的…反正 execute 跑不出来改一下就是了，SQL 第一次跑不通太常见了。

基础不牢，不问自己怎么学的，问别人为什么？？？？

为什么不体谅你？？？

@yolee599 就这一条就得在阿里背一个 3.25

说白了就是没怎么写过呗，确实是不扎实，没什么不好承认的。
基础能力是最好考察的，你解释了也没用。

很正常，我以前面试也遇到手写 sql 的，很简单的分页查询，我 limit 用法都用错了。也经常遇到很简单的问题，也回不上的情况，多投多面就行了，面完及时复习，不要被影响到心态

干过后端会记得比较深把，虽然用也用 ORM ，但实际上调试、测试、线上排查都是直接手写的的多，跟骑自行车一样很难忘记了。

我也不会，因为我天天在用 dynamodb 啊。。。

正经点：这东西面试前要复习的，和八股文差不多了

请你说一下 Redis 有哪些数据结构
`我不知道，但是我每次需要用的时候会用 GPT 问一下(我会用 GPT 哦，你肯定不会用)`

请你说一下 Redis 实现分布式锁有什么优缺点
`我不知道，但是我每次需要用的时候会用 GPT 问一下(我会用 GPT 哦，你肯定不会用)`

请你说一下你们这个项目为什么用 Postgres ，而不是 MySQL
`我不知道，但是我每次需要用的时候会用 GPT 问一下(我会用 GPT 哦，你肯定不会用)`

@yuanmomo 还好我都是 select 8

因为没用 AI 。你跟面试官讲讲 AI 有多火，讲讲 AI 的重要性，他再不会 AI 机会被淘汰。

还是写的少，我是做 MES ，几乎全部时间都是在写 sql 、函数、包，单条 sql 在 plsql 美化后最长记录是 1500 行，啥优化手法都信手拈来

好像除了后台查询数据有时候还需要用到手写 sql ，但基本上也是很简单的够用了。编写代码更用不上，基本都是 ORM 操作，人家都封装那么好了，手写 sql 确实没啥意义。只适合考试用。

@wsseo 面试官：你跟我说这些，我先把你淘汰了再说

不要因为别人的筛选机制内耗自己，
人家完全可以因为你左脚先踏入考场，把你 pass 掉。

ORM 用多了呗。

面试全靠运气，你以为你能答上来就会要你了么。别内耗了，看开点吧。

@daodao #23 ORM 只是封装而已，它们不对性能负责。不管是自己开发还是审阅同事/AI 的 SQL ，都需要对性能优化有了解。

不用说复杂的，UPDATE JOIN or SELECT 两层 JOIN ，没有很复杂的逻辑，优化一下就能把 SQL 时间降一个数量级（ SQL 30 行 107 个 word ，3 个表）。只是每人业务不同，有的场景下不涉及到而已。


@zerovoid #25 附议。在现在买方市场下，面试不为应聘者负责，招聘方自由度很高，面试时的表现、纰漏、面试官给的理由，都可以看开点

美国大公司面试已经不用刷题了，直接让你带 ai 上面试

@wulin2008 这是大屏报表类需求吧。

工作七年，面试时候也写不出来 sql 。只要让写手写 sql ，从来没完完整整写出来过。

@CEBBCAT 我读起来没啥问题啊，该停顿的时候写了逗号，

除了`实在不会问 ai 提供思路能解决 90 的 sql 。`，这里的 90 应该是 90%，以及 ai 之后应该加一个逗号会通顺许多。

看起来不是真正意义上的全栈。排查问题场景有吧？ dba 维护也有吧？洗数据有吧？（就不说要统计出数了）都是要手写 sql 的，即便你按 tab 补全，这东西你一旦写过，这辈子都不会忘记的

手写不了 sql ，全是 ai 写的，自然语言 -> SQL 基本不会出错

那还有什么好说的,sql 都写不出来就是不合格

进阶的话，用 orm 也应该对 sql 长什么样子有个了解，这样在一些场景优化里有所帮助，比如 force index

当然，也可以说：“我就一个 crud ，orm 不断 tab 完事了，管它 sql 啥样， 查出来不就得了”

某些特定系统上确实依赖手搓 sql 比较多 比如制造生产上的系统 mes ，erp 之类的，本身系统设计上就偏向于直接用 sql 来完成需求和解决问题，就算你想用代码来替代 sql 也是不支持的，在这种行业多干几年确实 sql 会手搓的飞起。

@edisonwong 现在我都习惯让 ai 给一个初版，然后直接调试，哪里错了改哪里

看到这个帖子，我也刷新了一个新的认知，就算有了 AI ，自身的技能也不能丢，这就是佐证。

写 SQL 最厉害的估计就是：DBA > 大数据 > 后端 > 其他

张无忌 练成太极后 还会不会记得招式

简单的增删改查、子查询、join 、索引写不出来那真没办法录取。。。

写不出来意味着你对 sql 一点都不熟悉，用 orm 你都不知道怎么优化

还是写的少，如果经历过一个存储过程上千行 sql 的毒打，形成肌肉记忆，那脑子忘了也能上手就写。

越是全栈，越是记不住具体操作

SELECT FROM WHERE 执行的先后顺序是什么？

我一直抵制 ORM ，建议不要用 ORM 。

现在 AI 确实强，不太需要自己写 SQL 了。

你可以不写不用，但不能不会。别把问题推到什么 ORM 、IDE 补全，AI 查询，就是基础不扎实。中国人多，人才也多，从来不缺基础扎实的人，不然为啥要中考、高考层层选拔？考试考的哪些知识是真天天用得上的？哪个不是可以通过 AI 查得出来的？为啥背不出、默不出就要被淘汰， 你说我会查字典、会解决问题，有啥用？一大把既背得出，还默得出，信手捏来的人不会用 ORM 么？拼的就是基本盘。

我个前端昨天面试也是被问 sql ，还问 python 不用 request 等任何 lib 的话怎么发送 get 请求，我瞎猜个 urlib3 ，然后直接把我挂了

@lesismal 没办法，其他语言没有 golang 的 sqlc

@ZGame #30 我们公司的 MES 系统，逻辑都是写在数据库的，应用界面只是简单的展示，所以每天都是写 sql 、优化 sql ，我又是做计划排程的，逻辑又多又复杂，sql 写多了就熟练了

那确实是不扎实 两年全栈真的差得远呢 大概让你手写 CSS 你也写不了复杂布局

别想多了，就算写出来也不一定会过，好好准备下一次就行了

面试和高考是一样的，本质是卷，看谁卷的厉害，这个形式不重要。举个例子，你 github 每天全绿，你写不出 sql 面试官也不会说你什么，因为你足够卷了。

@LandCruiser 毛线，不知道 github 可以刷的吗，每天全绿更可疑好吧。要不机器人刷的，要不就是每天上班工作不饱和偷偷写自己项目。你看那些 996 的大厂员工，多少个 github 全绿？

写得少的原因。或许你的工作中也比较少接触报表类的需求吧。我以前写报表类比较多，业务也有很多要自己写 SQL 的，我应该还好

细节不记得正常，这些东西真用到的时候随时查反而不用记。所以面试需要复习，该背的还得背

就是垃圾啊，外包更是狗都不去，必要了垃圾生，不如投海外程工作

躺了八个月刚进腾讯外包。。。

@YoYoLikesCiCi 腾的外包怎么样啊，我不关心歧视什么的，真的有双休吗

面试者太多了
还需要考察你的服从性，稳定性，确保你能抗压力，稳定干活
所以要问这些并不实用的知识点

基础素养不合格，上层工具用的再溜也只是个打工仔
理工科死磕基础的铁律永不过时

我怎么就想不到这种水贴的话题。

假如面试官让弄个高阶复杂的查询，sql 可以很灵活的组合构建，orm 就傻眼了。
上层工具把基础屏蔽不代表不需要重视基础了

比较疑惑，就算有 orm ，如果要做报表类的基本都要写 SQ 吧 ？

再依赖 AI 或 ORM...关键字顺序和简单 SQL 写不出来都很离谱吧。只是原来 SQL 掌握的就不行，AI 的出现解决了需求但是掩盖了问题。

浴皇大帝乔杉曾说过：不是你不够优秀，而是哥的要求有点高。

现在这行就是对记忆力不好的不友好

我工作中遇到的所有问题都能独立解决，但之前面试拿到最多的面评就是“深度不够“。自己做面试官后，从用人方的视角重新审视这一切，排除我没见过的那些高端面试，大多数面试（我通过各种方式参与或了解到的）都只是双方在逢场作戏，问题流于表面，拿到的结果比 vibe coding 的还要 vibe 得多。没表演好不是你不行，只是你还得练

@zhengfan2016 sqlc 生成代码的方式、性能当然是最好的，但也有不方便，比如一个 tx 、后续 tx 多个操作、操作之间还有一堆其他代码逻辑，这种如果修改功能之类的，也是麻烦。sqlx 、ent 我也都觉得不好用，所以我自己搞了个 sqlw ，raw sql+自动的 struct 绑定，日常用着省力多了。比如：

model := Model{
I: 1,
S: "str_1",
}

result, err := db.Insert("insert into sqlw_test.sqlw_test", &model) // 也可以 insert []model
// result, err := db.Insert("insert into sqlw_test.sqlw_test(i,s)", &model) // insert the specified fields
if err != nil {
log.Panic(err)
}


var models []*Model // type []Model is also fine
result, err = db.Select(&models, "select * from sqlw_test.sqlw_test")
// result, err = db.Select(&models, "select (i,s) from sqlw_test.sqlw_test") // select the specified fields
if err != nil {
log.Panic(err)
}

就是基础不行。
面试类似考试，平时有计算器 考试也不能用啊。
而且大公司基本上用接近原生的比较多。比如 mybatis ，spring 自带的 jdbc 等等。

最近天天优化 sql ，反而不太想用 orm 了，sql 一眼就知道干什么的而且非常清晰

面试大炮打飞机, 实际天天在后勤拧螺丝

@wulin2008 #50 开发写着不痛苦吗...

@ZGame #73 工作嘛，哪有快乐的，写多了就习惯了，跟用 C#、java 写逻辑大差不差。
写多了，不知不觉，我这的功能，单条 sql 经过 plsql 美化后最长都 1500 行了，每次改 bug 都得看半天，没注释、名字用拼音首字母命名、abc 这种的看起来简直吐血

@wulin2008 #74 我们也是做 MES 的 但是是在代码里写。 涉及到 erp 同步的都是通过 erp 的 api 或者 sql 同步到库里。 除了交付喜欢写 sql 开发自身还是对鞋 sql 很难受。。

@ZGame #75 我们是 PC 端的 mes ，08 年的老技术模式，当初是找供应商做的，项目交付后才自己人接手维护，只能继续延续供应商的开发模式。供应商的设计者就喜欢在数据库里写逻辑，一套一套的，看得人都麻了，搞得现在都没跟敢优化底层逻辑。
至于 erp 同步，一样的各种坑，我们这边大小系统一堆，每次数据同步出问题都是各种甩锅。

@wulin2008 #76 甲方的 it 吗 确实有点蛋疼....