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

2021-09-02 18:35:48 +08:00
 wh469012917

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

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

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

17926 次点击
所在节点    程序员
206 条回复
zhouyou457
2021-09-03 16:48:23 +08:00
简直就是在说我司的开发！

手上的项目有 n 多一句 sql 完成的功能，什么先查出 id 再 in 查询，各种拼接子查询，结果合并计算、标准时间格式化成前端格式字符串，然后结果集一律字符串返回，连封装都懒得写，直接 Map<String,String>
wh469012917
2021-09-03 16:51:47 +08:00
@l00t 为什么要设计一个成绩表？是因为一个学生一个科目，可能存在多次考试吗？如果是的话，所有科目成绩 >= 80 是指这个科目的每次成绩，还是某一次成绩？
zgcwkj
2021-09-03 17:01:27 +08:00
@zhouyou457 先查询出 ID，可能是嵌套的 sql 会影响性能吧，我试过直接用 in(selete id) 的时候会特别慢的。我认为不能直接否定，得看需求。嵌套的查询很影响 sql 性能的，从而影响其他的业务
l00t
2021-09-03 17:02:34 +08:00
#122 就一次考试
l00t
2021-09-03 17:03:17 +08:00
另外你的 ID 是不是犯禁啊。一 @就会触发验证。是不是 69 两个数字导致的？
l00t
2021-09-03 17:03:40 +08:00
咦好像也不是，这次就没触发
ytmsdy
2021-09-03 17:04:01 +08:00
@xz410236056 DBA 一般是解决数据库底层的一些性能问题，比如说 cache 命中率过低，根据情况设置索引，设置一些联合主键等问题。但是到开发层面的基础 SQL 编写，一般是不会介入的，要不然 DBA 要累死！
l00t
2021-09-03 17:04:54 +08:00
@followyourheart 题很简单，能写对的十不存一，我也很惊讶。
ytmsdy
2021-09-03 17:09:44 +08:00
@l00t 第一眼看到这个问题，我也愣住了。后来想了想，直接把 80 分一下的学生排除掉就可以了！
ytmsdy
2021-09-03 17:13:49 +08:00
现在的开发越来越脱离底层开发，上手就是 ORM 一般梭哈，连 SQL 都不需要会，也能做 CRUD 。
从另外一个方面来看，越来越多非科班出身，直接在培训班速成出来的开发人员，虽然看着很唬人，但是涉及到一些具体算法，数据库设计，性能分析就完全抓瞎了。
公司的管理层也只管功能上线能用就好了，技术层面的代码实现，业务逻辑处理完全不会！
Brentwans
2021-09-03 17:14:19 +08:00
的确，特别是去有钱但是 IT 部门没什么事的客户，很多小问题数据库完全可见处理的，一定要上 XXX 项目。我曾经处理过一个客户，处理 XXX 一定要上 spark，但是机器就 3 台老服务器，内存 16G...无所谓的，你可以想一下为什么这个破机器要上 Spark ？达到目的皆大欢喜
解决问题有的方法简单，有复杂的，有些看似简单实际运维复杂，有的还有利益关系。甚至有时候刚好研发同学最近看了某些工具或者方案，于是就用了。
我现在觉得最终能够稳定解决问题的方案，至少不算差，至于其他的不太重要了。
Cbdy
2021-09-03 17:18:01 +08:00
但是，代码写得好，有用吗？

事实是没用，所以写得烂

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

至于分布式集群、消息队列这种听起来高大上的东西当然要背得头头是道，这样才能提高身价，让老板满意，让面试官满意
Veneris
2021-09-03 17:37:01 +08:00
唱个反调，有一部分愿意是这样的。

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

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

项目的平稳发展比所谓的写好 sql 更重要。
lap510200
2021-09-03 17:45:20 +08:00
小公司小项目就这样，很多人写代码， 表面上运行没问题，但是 ide 报各种警告异常，像我这种洁癖的人，看着很难受，看都懒得看，很多还不是科班的，有的人还比较倔的，不好说的
Macolor21
2021-09-03 17:53:47 +08:00
@hhjswf 看一下 GraphQL 怎么解决 N+1 的，用 DataLoader，核心思想是 @followyourheart 提到的，list1 拿到里面的关联键，通过这个键（ id ）集合用 in 一条查询出来，然后映射成 Map<id,List Or Object>
cassyfar
2021-09-03 17:54:54 +08:00
其实我觉得挺正常的，大厂挺多人都没机会接触 sql 了。选择后端数据库都是 nosql 的。
wh469012917
2021-09-03 17:55:08 +08:00
@Cbdy 代码写得好是没用，但是写得烂就有用吗？“996 、PUA 、拖欠工资、251” 这些问题不会因为你代码写的烂就能解决。而且相对好的代码，后续自己维护和版本迭代，对开发效率之类都是有好处的
wh469012917
2021-09-03 17:58:44 +08:00
@Veneris 你去试试一个，n+1 查询，命中索引，看看整体的时间怎么样就知道了
Cbdy
2021-09-03 18:21:31 +08:00
@wh469012917 写得好的代码要花时间，写得烂的代码可以更快出活，这样就可以 996，避免 700，剩下一天休息一下舒缓一下 PUA 的压力，至于后续维护和版本迭代，就管不了这么多了，谁知道后续还是不是原作者维护和迭代呢

我不是说这是对的实践，但是业界事实，毕竟成年人的世界没有对错，只有打工
rsyjjsn
2021-09-03 18:29:18 +08:00
理想情况是每个人都好好写 sql，其实 bug 会更少，但是有用吗？现在的招聘动不动就是分布式集群以及 k8s，工作了 1 年，这些总得去学去实践吧，那怎么实践呢？那当然是在现成的项目里面实践啊，难不成我写了 1 年代码，整天研究 sql 怎么写更加快？面试官可不会问你那么多 sql 相关问题。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/799533

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX