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

[wh469012917]

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

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

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

[wh469012917]

@opengps 对的，分布式微服务架构，是一把利剑，但其实大部分中小应用都用不到，单体应用一把梭了

[wh469012917]

@yanzhiling2001 可以去学习一下 mysql，都说 IO 是 Web 应用的性能瓶颈，而 SQL 查询是 IO 最重的地方，优化一条慢查询，比你做什么集群分布式都好用

[xinJang]

@wh469012917 这种应该直接关联表查询，子查询 count 吧

[wh469012917]

@xinJang 对的，关联查询一条 SQL 就能搞定了，按照遍历的方式，列表越长执行的 SQL 数越多

[wangyzj]

会做不如会叫
叫得好听肯定更容易被喜欢

[xinJang]

@wh469012917 这里我想引申一个问题。就是最近有个项目用得 spring boot，orm 框架是 jpa 。这里关联查询出来的数据，关联表的字段没法映射到实体类，网上没找到好的解决方式，这种有遇过么？

[final7genesis]

@wh469012917 第一次就把系统做好了，没有优化空间，系统上线没问题，然后老板把研发开了，留下几个运维人员

[zhuzhibin]

习惯就好 动不动就分布式、高并发、微服务 我身边也很多这种人，他们可能仅仅是看了一篇文章，就开始吹，各种熟悉 xxx，问起来或者动起手来，就尬住。

[lizhenda]

其实就是不会不重视不想学

[wh469012917]

@zhuzhibin 我们每天访问量不大，也就百万级别，而且并发不高，写好 sql 其实可以解决大部分问题了

[wh469012917]

@lizhenda 差不多这个意思，学起来不难，就是不想去学，能用就行

[stach]

楼主说的有道理, 不过单看你举的那个例子, 如果 `用户发表的动态数量` 这个表很大的话 (上千万), 你同事做的并没有问题.

[stach]

更好的做法是, 设计一张独立的用户统计表, 把 `动态数` 存起来, 单独维护, 这样就可以批量查询用户的动态数量了.

[Latin]

同事：你在教我做事啊！ （狗头

[offswitch]

@wh469012917 join 确实难用，就你说的这个，list 估计也不大，像 count 可以优化一下，改成读缓存。

[summerLast]

@xinJang @Formula 看看这个注解

[chendy]

因为这种操作更容易让外人觉得自己很厉害，更容易找到吹逼的资本然后找下家
深耕业务各种优化也可以，但是要注意自己做记录做统计，因为不懂的人真的不知道你在干啥

[thtznet]

国内风气如此，不加点新名词怎么显得高级（华为别骂我）？ SQL 用来几十年太成熟了，爆点不好搞出来嘛。

[wh469012917]

@stach 我是为了避嫌，所以假设了一个业务场景，而且下文也说了，数量级不大，单表最多也不过 2000w，过早的优化是万恶之源，只要写好 sql，基本上 ok

[wh469012917]

@offswitch join 不难用，只是心里害怕罢了；读缓存如何保证数据一致性呢？