V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wh469012917  ›  全部回复第 8 页 / 共 9 页
回复总数  175
1  2  3  4  5  6  7  8  9  
@jtwor 对,这样也确实比较建议;但是奈何不会啊,都是遍历这个 id list,然后一条条 where id = ? 这样去查询,妥妥的拉低性能
@daguaochengtang 正常,瞎说又不用有什么成本
@neoblackcap 这样说其实也对,也可以把 join 拆出来,分开查询也可以,但是 n+1 以及 in 查询,这些算是基本功了
@wxy1991 多了去了,可能你们也存在 n+1 的问题,只是没发现而已; google 搜索一下 sql n+1,这个在使用 orm 的时候比较经常遇到
@calming 面试问不问是一回事,至少自己要懂这些东西吧,sql 算是基本功了
@dcoder sql 手写难受,那用个好用的 orm 可以解决大部分 sql 问题了。就比如 laravel 的 orm,基本上都不用手写 sql 了,但是虽然不用自己写,但是原理还是要懂,至少最简单的 in 查询要会吧
@zxCoder 不积跬步,无以至千里
@thtznet 这个倒也是,国内风气确实也不大行,我上一家公司,一个没啥访问量的公司内部系统,都得用上全套的微服务架构
@offswitch join 不难用,只是心里害怕罢了;读缓存如何保证数据一致性呢?
@stach 我是为了避嫌,所以假设了一个业务场景,而且下文也说了,数量级不大,单表最多也不过 2000w,过早的优化是万恶之源,只要写好 sql,基本上 ok
@lizhenda 差不多这个意思,学起来不难,就是不想去学,能用就行
@zhuzhibin 我们每天访问量不大,也就百万级别,而且并发不高,写好 sql 其实可以解决大部分问题了
@xinJang 对的,关联查询一条 SQL 就能搞定了,按照遍历的方式,列表越长执行的 SQL 数越多
@yanzhiling2001 可以去学习一下 mysql,都说 IO 是 Web 应用的性能瓶颈,而 SQL 查询是 IO 最重的地方,优化一条慢查询,比你做什么集群分布式都好用
@opengps 对的,分布式微服务架构,是一把利剑,但其实大部分中小应用都用不到,单体应用一把梭了
@wangbenjun5 我有委婉提过这个问题,他们说 JOIN 太难用了
@xinJang 你想多了,举个这个的需求:在一个用户列表里,显示用户发表的动态数量;他们的实现就是先把用户列表取出来,然后遍历这个 userList,然后取其中的用户 ID,再一条条 SQL 去 count 用户的动态数量,在组装到用户实体上
@GiantHard 木有 code review
@Acoffice 我倒是更认同你这个说法
@palfortime 就算 in 能这样解释,那 n+1 呢?这个可是妥妥的拉性能的查询
1  2  3  4  5  6  7  8  9  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2610 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 06:50 · PVG 14:50 · LAX 22:50 · JFK 01:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.