为什么很多人连基础的 SQL 都写不好，却开口闭口就是缓存架构分布式？

@wh469012917 领导跟你感受估计一样，想改也改不了

@l00t 这题比较标准的解法是 join 表后 group by 学生 id 再 having 分数＞ 80 分的数＝科目数吧，而且还要考虑到有学生没考过试的

那是因为你没见过 一个 select * 可以完事的，别人 select 第一列 ，select 第二列 ，select 第三列 （每次只出一个数据那种）

这叫快餐式开发

@l00t 这样写应该可以吧，没运行。应该不需要用到聚合函数
select * from student std
where not exist (
select 1 from subject sbj
inner join scorce sc
on sc.subjectId = sbj.subjectId
where std.studentId = sbj.studentId
and sbj.scorce < 80
)

话说起来，不记得是谁，推荐任何人想要学第二门语言都应该学 SQL
争什么 Python Go JavaScript 什么的，第二门语言最应该是 SQL
不少人推荐第二门语言采用不同的范式；而 SQL 可以说是目前生产环境上广泛运用的唯一一门描述式语言了。

顺便摘个发言：『如果你的同事全都不如你，那么是你该跳槽的时候了』

@Cbdy 扎心了

IT 行业盛产臭鱼烂虾

N + 1 是基础 + 原则问题，这个都不当回事要我我就铁拳了。这个达不到，谈别的都是吹逼。

就算不喜欢写 SQL，也得搞 batch 解决这个问题才行。

至于 SQL 为啥经常被忽视是因为 SQL 逼格比分布式低，用得早，想到 DBA 和存储过程就能想到那些老掉牙的项目。所以人们都喜欢拿分布式包装自己。

@l00t
没有表结构 斗胆现丑
select * from 学生表 where uid in(
select uid from 成绩表 where 分数>=80 group by uid)

面试主要就问这些啊，现在面三年以上的几乎没有笔试，谈起 SQL 优化头头是道，真要是手写没几个能过的

总觉得是一些公司推广自己的“规范”，加上一些人无视实际情况盲目使用其他公司的规范导致的麻烦。我相信制定这些规范的程序员知道自己在干什么，但是我非常质疑那些盲目执行这些规范的人知不知道自己在干什么。

好奇你们这个产品有多少人在使用？

N+1，项目初期，或者量小的时候，可以不用优化。
但是数据量大了，开始针对热点优化的时候，还不知道去改，那是真的不应该。
当然，有些坑不亲自跳一次是不知道的，这些人可能就是经验太少，没跳过这坑，你只要不提他们就根本不知道要这么做。

@onhao 你这个写错了，学生只要有一门考过 80 就符合条件了。要先按学生分组，取最小值，最小值也高于 80 就没毛病了。所以要用 having 去筛而不是 where 。

面向面试编程

sql 不一定要用 join，我目前都是单表查的，再用 dto 组装也可以。

因为这是时尚
你不跟着走，哪怕性能好也是落伍

> 我们公司同个部门的好几个同事

多个成员存在这样的问题，说明这是团队（负责人）的问题，而不是孤立的某几个人的问题。

如果要从团队层面系统地解决这个问题，推荐两个实践：
1 ）引入压力测试 /性能优化，对于数据量千万级以下的传统应用，要求单机支持 1k+ tps 、100- ms latency，可以在设计 /开发 /测试环境快速识别性能瓶颈，避免低质量的设计和开发；
2 ）引入 Application Performance Monitoring 工具，数字化直观展现应用在生产环境的性能瓶颈，将慢操作视为高优先级技术债务，对应的产品有 SkyWalking 、New Relic 等等。

通过建立体系化的开发流程，即使新的工程师加入时没有相关的经验和意识，处理几次相关问题后也能逐渐适应和融入。
当然，这对团队负责人的技术能力和管理能力要求就比较高了。
如果楼主部门领导不具备这种能力，楼主描述的问题必然会反复出现。

有库表设计和 SQL 规范嘛