非 includes
includes 之后，
AR 耗时反而增加，有什么说法吗？
其中，includes 的实体查询中，现有数据记录 id IN (...) 大约有 5000 条左右，应该不大，但这一查询明显稍微迟延了一下，这部分是否有影响？
避免了 N+1 的查询，但结果令人 尴尬！
Update
问题详细些
由于之前的数据库模型设计上的问题（老系统），需要从两个数据表中，查询出数据，并关联其它数据表 s，计算并得到预警的信息， 非需要预警的记录是不需要的；
两表的统计字段也是不一样的；
两表的数据结果是要一起得出，合并的。
所以，分页 offset 是不太可能的
@shatle 一般统计也会在数据库层面用 SQL 做，不会全用 AR 查出来在 Ruby 层面做的。当然这只是我猜测的你的做法。你不妨说说业务场景，不然没人懂你这是什么意思
@shatle 如果我没理解错，你需要从两张主要的表中筛选合并一些数据，如果你业务逻辑需要，分页是可能的，字段统一也不是问题。你可以在 SQL 层面用 AS 和 UNION 做。当然这不是唯一的做法。前段时间还有人问过 UNION 如何做分页的问题，就不多说了。
另外，作为 web 开发者，SQL 是必学的技能，不是喜不喜欢的问题。你这个说法就像是写 Rails 但不太喜欢 Ruby 一样。
用 explain 看 是否 in 用到了索引。当你的 in 的字段数组太多的时候，反而会导致索引失效（你 in 了 5000 条）而增加了时间。includes 最后也是执行的 sql 语句。建议 lz 看下 AR includes 的文档
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
