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

wh469012917 · 1 天前 · 7534 次点击

说下情况，我们公司同个部门的好几个同事，连个基础的 SQL 都写不好，代码中一堆数据库 N+1 的问题，连个 WHERE IN 查询都不会用，涉及到批量查询，都是遍历然后一条条的去跑 SQL，同一个方法重复查询了好几次，数据库设计更是不行，外键都是用逗号分隔拼接成字符串，然后保存到主表上。

正因为 SQL 写的烂，所以接口性能很差劲，但是他们好像都不在意这些 IO 方面的优化，整天在想着怎么优化语言性能，比如反射、JSON 序列化、语言基础库的性能；要么就是上集群、加缓存，然后又没有任何设计模式，直接业务代码中强硬加入缓存读写，就算是缓存也是先从缓存读出数据，然后遍历一条条去数据库再查出来，性能更差了

其实整体项目量不大，好好写好 SQL，基本上能搞定 90% 的性能问题了，大部分的开发经验也都好几年了，不至于这种基础知识点不懂，可为啥就是不重视 SQL 性能

147 条回复 • 2021-09-04 00:13:12 +08:00

xinJang 11 小时 3 分钟前

@summerLast 试了下，空指针。
我本身 sql 是个模糊搜索的查询，里面本来就有 left join 语句，可能不适合我这种场景

Canon1014 10 小时 59 分钟前

还不是被逼的

qrobot 10 小时 59 分钟前 1

因为 SQL 写的再好，比如中间件的一次缓存命中，如果缓存命中率达到 90% 以上，那么就不存在 IO 问题。

```
正因为 SQL 写的烂，所以接口性能很差劲，但是他们好像都不在意这些 IO 方面的优化，整天在想着怎么优化语言性能，比如反射、JSON 序列化、语言基础库的性能；要么就是上集群、加缓存，然后又没有任何设计模式，直接业务代码中强硬加入缓存读写，就算是缓存也是先从缓存读出数据，然后遍历一条条去数据库再查出来，性能更差了
```

我不清楚你们的项目结构，不过 IO 在怎么优化是有瓶颈的，为了提高命中缓存，我觉得不用 in 和 left join 是最好的

dbpe 10 小时 57 分钟前

@xinJang 现在我是用..jooq 或者 querydsl 去解决...不过我还是尽量单表查询,然后去合并查询请求...list 遍历去查不靠谱

Akiya 10 小时 56 分钟前

这个你得怪市场需求，不要怪同事，公司招什么样的人，就会得到什么样的人

cedoo22 10 小时 53 分钟前

技术面试到面试数据库知识的时候分两种，一种给个场景直接问 SQL 怎么写，另外一种是问你数据库集群 balabala，

wh469012917 10 小时 51 分钟前

@qrobot 但是我们数据量并不大，并发也不高，基本上写好 sql 能处理大部分场景了，缓存架构什么的等业务起来了再搞也不迟

xinJang 10 小时 48 分钟前

@xinJang 不能使用自己的 sql 查询不然就空指针无解

followyourheart 10 小时 45 分钟前

@ipwx #66 你说的这种临时表不应该是我们优化的对象避免产生临时表吗

hhjswf 10 小时 43 分钟前

我们总监不让用 join 的...n+1 怎么避免..

xinJang 10 小时 35 分钟前

@dbpe 没看太明白。如果你是先查单表，拿到的数据是一个 list 吧，这时你不遍历查询怎么组合数据？这里还有个问题，那就是分页数据，组合之后的数据长度有时是不一致的，那就会变成翻第 2 页只有 1 条数据的可能

flybluewolf 10 小时 35 分钟前

@hhjswf 笑死，关系型数据库这么多年理论研究都白搞？不要 join，那还玩什么集合论？所有关系型数据库都移除 join 操作好了！具体项目具体研究，基本上 99%的项目关系型数据库足够满足要求，性能问题都能通过 sql 语句+索引解决。

flybluewolf 10 小时 32 分钟前

@dcoder 动则都分布式？ CPA 咋解决？

followyourheart 10 小时 21 分钟前

@hhjswf #110 查出来 list1 然后获取 idList 根据 idList 一次性查出数据集合 Map<id,Object>，然后遍历 list 根据 id 从 Map 取出数据，组装数据，不知道有没有更好的方法

jun771480011 10 小时 14 分钟前

因为 SQL 写不好，所以张口闭口就是缓存架构分布式！

dream4ever 10 小时 13 分钟前

@wh469012917 他们这个智商，就告别这一行吧

l00t 10 小时 13 分钟前 1

@vjnjc 我们面试有一道 SQL 题，大致是这样的，有一个学生表，一个科目表，一个考试成绩表。让用一条语句找出所有科目成绩在 80 分以上的学生。

看起来很简单吧？ 9 成的面试者没法写对。

skinny 10 小时 10 分钟前

现在这行不就流行堆砌分布式、集群、高并发、高性能、高可用等等这些看似高大上名词的风气吗？

连那些云服务大厂都一个鸟样，吹起来什么异地灾备、自动化、高可用有多少个 9，崩起来就 N 小时还全面崩

followyourheart 10 小时 3 分钟前

@l00t #117 查出最低分大于 80 的 group by 不就行了吗

dream4ever 10 小时 1 分钟前

@sagaxu 我一同事负责的一项业务有不少 SQL 查询，前一段时间发现服务器 CPU 经常飙到 100%，排查来排查去发现一堆慢查询，最后追根溯源发现数据库各个表所有被查询到的字段都没有设置索引……

zhouyou457 9 小时 55 分钟前

简直就是在说我司的开发！

手上的项目有 n 多一句 sql 完成的功能，什么先查出 id 再 in 查询，各种拼接子查询，结果合并计算、标准时间格式化成前端格式字符串，然后结果集一律字符串返回，连封装都懒得写，直接 Map<String,String>

wh469012917 9 小时 51 分钟前

@l00t 为什么要设计一个成绩表？是因为一个学生一个科目，可能存在多次考试吗？如果是的话，所有科目成绩 >= 80 是指这个科目的每次成绩，还是某一次成绩？

zgcwkj 9 小时 42 分钟前

@zhouyou457 先查询出 ID，可能是嵌套的 sql 会影响性能吧，我试过直接用 in(selete id) 的时候会特别慢的。我认为不能直接否定，得看需求。嵌套的查询很影响 sql 性能的，从而影响其他的业务

l00t 9 小时 40 分钟前

#122 就一次考试

l00t 9 小时 40 分钟前

另外你的 ID 是不是犯禁啊。一 @就会触发验证。是不是 69 两个数字导致的？

l00t 9 小时 39 分钟前

咦好像也不是，这次就没触发

ytmsdy 9 小时 39 分钟前

@xz410236056 DBA 一般是解决数据库底层的一些性能问题，比如说 cache 命中率过低，根据情况设置索引，设置一些联合主键等问题。但是到开发层面的基础 SQL 编写，一般是不会介入的，要不然 DBA 要累死！

l00t 9 小时 38 分钟前

@followyourheart 题很简单，能写对的十不存一，我也很惊讶。

ytmsdy 9 小时 33 分钟前

@l00t 第一眼看到这个问题，我也愣住了。后来想了想，直接把 80 分一下的学生排除掉就可以了！

ytmsdy 9 小时 29 分钟前

现在的开发越来越脱离底层开发，上手就是 ORM 一般梭哈，连 SQL 都不需要会，也能做 CRUD 。
从另外一个方面来看，越来越多非科班出身，直接在培训班速成出来的开发人员，虽然看着很唬人，但是涉及到一些具体算法，数据库设计，性能分析就完全抓瞎了。
公司的管理层也只管功能上线能用就好了，技术层面的代码实现，业务逻辑处理完全不会！

Brentwans 9 小时 29 分钟前

的确，特别是去有钱但是 IT 部门没什么事的客户，很多小问题数据库完全可见处理的，一定要上 XXX 项目。我曾经处理过一个客户，处理 XXX 一定要上 spark，但是机器就 3 台老服务器，内存 16G...无所谓的，你可以想一下为什么这个破机器要上 Spark ？达到目的皆大欢喜
解决问题有的方法简单，有复杂的，有些看似简单实际运维复杂，有的还有利益关系。甚至有时候刚好研发同学最近看了某些工具或者方案，于是就用了。
我现在觉得最终能够稳定解决问题的方案，至少不算差，至于其他的不太重要了。

Cbdy 9 小时 25 分钟前 via Android

但是，代码写得好，有用吗？

事实是没用，所以写得烂

自己的项目当然可以好好写，但将心比心，大多数人都是外出务工的农民工，能跑通过验收老板能接受就行了，何况还有 996 、PUA 、拖欠工资、251 能大山压着呢

至于分布式集群、消息队列这种听起来高大上的东西当然要背得头头是道，这样才能提高身价，让老板满意，让面试官满意

Veneris 9 小时 6 分钟前

唱个反调，有一部分愿意是这样的。

复杂 sql 可维护性差，绝大部分公司的绝大部分业务，都不会对 sql 如此苛刻，命中索引足够了。

但是人员的流动却是常事，业务逻辑都在代码里会更好上手，随便找个实习生也能接手代码。

项目的平稳发展比所谓的写好 sql 更重要。

lap510200 8 小时 58 分钟前

小公司小项目就这样，很多人写代码，表面上运行没问题，但是 ide 报各种警告异常，像我这种洁癖的人，看着很难受，看都懒得看，很多还不是科班的，有的人还比较倔的，不好说的

Macolor21 8 小时 49 分钟前

@hhjswf 看一下 GraphQL 怎么解决 N+1 的，用 DataLoader，核心思想是 @followyourheart 提到的，list1 拿到里面的关联键，通过这个键（ id ）集合用 in 一条查询出来，然后映射成 Map<id,List Or Object>

cassyfar 8 小时 48 分钟前

其实我觉得挺正常的，大厂挺多人都没机会接触 sql 了。选择后端数据库都是 nosql 的。

wh469012917 8 小时 48 分钟前

@Cbdy 代码写得好是没用，但是写得烂就有用吗？“996 、PUA 、拖欠工资、251” 这些问题不会因为你代码写的烂就能解决。而且相对好的代码，后续自己维护和版本迭代，对开发效率之类都是有好处的

wh469012917 8 小时 44 分钟前

@Veneris 你去试试一个，n+1 查询，命中索引，看看整体的时间怎么样就知道了

Cbdy 8 小时 21 分钟前 via Android

@wh469012917 写得好的代码要花时间，写得烂的代码可以更快出活，这样就可以 996，避免 700，剩下一天休息一下舒缓一下 PUA 的压力，至于后续维护和版本迭代，就管不了这么多了，谁知道后续还是不是原作者维护和迭代呢

我不是说这是对的实践，但是业界事实，毕竟成年人的世界没有对错，只有打工