Rails includes 之后,AR 速度反而降低?

shatle · 2016年11月05日 · 最后由 shatle 回复于 2016年11月09日 · 2026 次阅读

非 includes

includes 之后,

AR 耗时反而增加,有什么说法吗?


其中, includes 的实体查询中, 现有数据记录 id IN (...) 大约有 5000 条左右,应该不大,但这一查询明显稍微迟延了一下,这部分是否有影响?

避免了 N+1 的查询,但结果令人 尴尬!

Update

问题详细些

由于之前的数据库模型设计上的问题(老系统),需要从两个数据表中,查询出数据,并关联其它数据表 s,计算并得到预警的信息, 非需要预警的记录是不需要的;

两表的统计字段也是不一样的;

两表的数据结果是要一起得出,合并的。

所以,分页 offset 是不太可能的

AR 和整个请求耗时如此长,id IN 有 5000 条。正常页面不会查这么多数据。你们这是什么页面?

数据统计接口

@shatle 一般统计也会在数据库层面用 SQL 做,不会全用 AR 查出来在 Ruby 层面做的。当然这只是我猜测的你的做法。你不妨说说业务场景,不然没人懂你这是什么意思

@darkbaby123 上面有更新,稍微说明了应用场景。SQL 知识相对不了解,同时,语义上不明了,本人是不太喜欢用 SQL 写逻辑

@shatle 如果我没理解错,你需要从两张主要的表中筛选合并一些数据,如果你业务逻辑需要,分页是可能的,字段统一也不是问题。你可以在 SQL 层面用 AS 和 UNION 做。当然这不是唯一的做法。前段时间还有人问过 UNION 如何做分页的问题,就不多说了。

另外,作为 web 开发者,SQL 是必学的技能,不是喜不喜欢的问题。你这个说法就像是写 Rails 但不太喜欢 Ruby 一样。

→_→,扯偏了,我爱好而已。

我只是想知道 includes 之后,ar 耗时增加的原因,

sql 中,id in 是不是没有利用到索引,导致性能有差异?

#7 楼 @shatle in 命没命中索引要看你 source 字段唯一性高不高,贴出你的数据结构一目了然

用 explain 看 是否 in 用到了索引。当你的 in 的字段数组太多的时候,反而会导致索引失效(你 in 了 5000 条)而增加了时间。 includes 最后也是执行的 sql 语句。建议 lz 看下 AR includes 的文档

是不是磁盘 IO 性能超低?

IN is generally equivalent to a list of OR for most database engines, and when you have a big list of OR, it generally makes the query unsargable (不优化搜索), and switches to full scan. In such situations, it is more sensible to use join instead.

To use join and to avoid N+1, you can use references (http://apidock.com/rails/ActiveRecord/QueryMethods/references), which generates a LEFT JOIN

@mengqing 谢谢啊,虽然已经知道了

shatle 关闭了讨论。 11月09日 19:42
需要 登录 后方可回复, 如果你还没有账号请 注册新账号