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

[wh469012917]

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

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

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

[wh469012917]

@thtznet 这个倒也是，国内风气确实也不大行，我上一家公司，一个没啥访问量的公司内部系统，都得用上全套的微服务架构

[zxCoder]

正常，我还没毕业呢，找工作看的也都是分布式架构啥的，写 SQL 这种平时自己小项目也不会在意，面试也不怎么问

[MoYi123]

确实，我也碰到过有些人，4 种事务隔离级别倒背如流，写 sql 要把某个数字-1 的时候，要先弄个 redis 锁，select 出来再 update 。

[wh469012917]

@zxCoder 不积跬步，无以至千里

[dcoder]

1. 因为精通 SQL 对跳槽, 尤其是互联网高薪的职位, 好处很少
大家都是面向简历编程 XD

2. SQL 确实表现力很弱, 很多时候用着别扭. join, 甚至自带的外键什么的, 搞分布式挺忌讳的.
其实我觉得 SQL 能流行, 就是整个行业之前把科技树点歪了... 这个说来就话长了... 但是从目前大环境看, SQL 用起来方便的时候, 该用还是得认真学, 正确地使用

3. SQL transaction VS distributed lock (Redis)
使用在 1 个 db, 1 个 service 时候, SQL transaction 好用
逻辑稍微复杂点, 跨 db/services 的时候, 还真得用 distributed lock

[jtwor]

中间件工程师。。

[xx6412223]

太多了，
分布式锁：不管运维，成本，稳定性，就要上 zookeeper 啥的。用 sql 写一个排他锁不会，数据库乐观锁没听过

[nekoyaki]

点进来之前我以为楼主指的 sql 写不好指的是不用存储过程 /触发器 /各种偏门函数 /复杂 sql 联查，还想说这些邪门歪道到了大数据量的生产环境以后再想优化就是受罪

结果点进来之后一看，哦连 n+1querys 和 where in 都不会用，那就确实是最基本的能力问题了……

[daguaochengtang]

这就像现在前端原生 js 基础都没搞懂呢，满口都是 vue 源码

[calming]

太畸形了，面试都要问分布式啥的，基本上平时都随便写写业务狂背八股文不就这个下场嘛

[offswitch]

@wh469012917 不是我写不好，这上面的人对 mysql 了解估计还没我深，写 join 很蛋疼，要处理起来太麻烦。

[wxy1991]

你这什么公司啊，我工作 5 、6 年都没见过 n+1 逻辑的代码，连用外键的都少，刚看到帖子的时候我还纳闷 n+1 是什么问题，感觉稍微脑袋正常的人都写不出来这种代码吧，而且像很多公司都是禁止使用外键的。

[jsjjdzg]

惭愧，SQL 写的不太好，有次面试喜欢的公司因为 SQL 不行被 Pass 了 = =

[silk]

@daguaochengtang 毕竟面试只问算法

[jsjjdzg]

自己练习的也少，公司的要求也是 SQL 不准使用复杂 SQL，能业务处理的就业务处理

[xuanbg]

基本功不行的，遇到问题只会照抄。而且不懂得变通，解决问题的手段往往极其拙劣。

[wh469012917]

@dcoder sql 手写难受，那用个好用的 orm 可以解决大部分 sql 问题了。就比如 laravel 的 orm，基本上都不用手写 sql 了，但是虽然不用自己写，但是原理还是要懂，至少最简单的 in 查询要会吧

[wh469012917]

@calming 面试问不问是一回事，至少自己要懂这些东西吧，sql 算是基本功了

[neoblackcap]

@wh469012917 join 的问题在于你把业务压在数据库层面上了，这个看规模。有的公司倾向于在代码层面上面解决这个问题。用不用 Join 得看情况。因为如果换底层了，count 的方式可能比较好改，join 的方式就不见得那么好改了（比如加缓存或者换数据库存这部分的信息）。

[wh469012917]

@wxy1991 多了去了，可能你们也存在 n+1 的问题，只是没发现而已； google 搜索一下 sql n+1，这个在使用 orm 的时候比较经常遇到