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

[wh469012917]

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

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

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

[infun]

可能是培训的

[charlie21]

方便搞大清洗，具体请 v 站搜大清洗

[felixcode]

他们理解的没有好好写 SQL，只是认为自己把逻辑和负载都放程序代码里了，SQL 不值得优化。
却没意识到 SQL 能力的孱弱已经是瓶颈。

[wh469012917]

甚至在优化 json 序列化、网络传输包、语言反射等性能，但是代码中 sql 查询一大堆的 n+1，那些优化等半死，才提升了几十毫秒的性能，大头全被 sql 占去了

[palfortime]

可能考虑以后量大的时候能够容易扩展？ in 的值多了也不走索引。

[wh469012917]

@infun 也不至于，都是工作了四五年了，再怎么培训的也不至于这么不行，其他缓存队列分布式，说的头头是道

[wh469012917]

@palfortime 就算 in 能这样解释，那 n+1 呢？这个可是妥妥的拉性能的查询

[Acoffice]

因为公司不在乎,领导不在乎,拿钱干活,至于活干的好不好,没人在乎啊!
最重要的是 很多人只是来挣工资的,至于自己的技术,凑合就行啊!
---
还有的是公司文化,得 有人造锅,有人甩锅,有人接锅 才能形成闭环,利益最大化!

[wh469012917]

@Acoffice 我倒是更认同你这个说法

[GiantHard]

Code Review 的时候提醒一下应该会改吧

[yanzhiling2001]

别说了别说了，感觉都是再说我。

大佬指点一下该怎么优化 sql，或者 怎么发现 sql 执行时间这个问题。

写 sql 从来都是随心所欲，拿出来数据就行了的。

[RRRoger]

i cannot agree more

[wh469012917]

@GiantHard 木有 code review

[opengps]

能被作为典型培训的教材，普遍都是分布式集群等环境下处理简单业务的模式。模式本身没问题，只是确实让一帮没理解透业务的人充了门面

[wm5d8b]

@wh469012917 培训的是有这种情况，工作多少年都一样，他们完全没有这方面的认知。另外，说的头头是道，不代表实际会用，许多人都是只会背诵

[wangbenjun5]

循环查 sql，确实致命，哈哈，不是懒就是真蠢！！！

[xinJang]

涉及到批量查询，都是遍历然后一条条的去跑 SQL

[xinJang]

@xinJang 这句没看明白。是查出 list 然后批量 update 或 delete ？

[wh469012917]

@xinJang 你想多了，举个这个的需求：在一个用户列表里，显示用户发表的动态数量；他们的实现就是先把用户列表取出来，然后遍历这个 userList，然后取其中的用户 ID，再一条条 SQL 去 count 用户的动态数量，在组装到用户实体上

[wh469012917]

@wangbenjun5 我有委婉提过这个问题，他们说 JOIN 太难用了