一、从慢查询开始的调优场景
很多用Ruby on Rails做项目的开发者，或多或少都遇到过这样的问题：页面加载半天没反应，或者后台导出数据卡得让人烦躁。最后查来查去，发现问题出在数据库查询上——也就是ActiveRecord生成的SQL跑太慢了。比如你做一个电商网站的订单列表，用户一进页面，要同时显示订单号、下单时间、用户昵称、商品名称，结果页面加载要5秒，排查后发现是每一行都单独查了用户表和商品表，这就是典型的慢查询场景。
ActiveRecord本身是很方便的ORM，不用写原生SQL就能操作数据库，但正因为它太“贴心”，很多时候开发者没注意到它生成的SQL有问题，慢慢就堆出了性能瓶颈。调优的核心不是写复杂的原生SQL，而是学会让ActiveRecord生成更高效的SQL，同时避免不必要的查询。
二、最常用的几个调优技巧（附完整示例）
先统一说明所有示例的技术栈：Ruby on Rails 7.0.8，PostgreSQL 14，示例代码基于电商场景的三个核心模型：User（用户）、Order（订单）、Product（商品），对应表结构简化如下：
- users表：id（主键）、nickname、email
- orders表：id（主键）、user_id（外键）、product_id（外键）、amount、created_at
- products表：id（主键）、name、price
2.1 避免N+1查询：用includes预加载关联数据
N+1查询是新手最容易踩的坑，也是最常见的慢查询原因。举个例子：你要获取100个订单，每个订单要显示对应的用户昵称和商品名称，错误的写法会先查100个订单（1次查询），然后对每个订单分别查1次用户、1次商品，总共就是1+100+100=201次查询，数据库要处理201次请求，速度自然慢。
正确的做法是用includes预加载关联数据，把多次查询合并成少数几次。完整示例如下：
# 错误写法：会产生N+1查询
# 先查100个订单（1次），然后每个订单分别查user和product（各100次）
orders = Order.order(created_at: :desc).limit(100)
orders.each do |order|
# 这里触发对users表的查询
user_nickname = order.user.nickname
# 这里触发对products表的查询
product_name = order.product.name
end
# 正确写法：用includes预加载关联
# 实际会生成3次查询：1次查orders，1次查关联的users，1次查关联的products
orders = Order.includes(:user, :product).order(created_at: :desc).limit(100)
orders.each do |order|
# 这里不会再触发额外查询，数据已经预加载到内存
user_nickname = order.user.nickname
product_name = order.product.name
end
这个技巧的应用场景是：当你需要遍历一批主记录，同时需要访问关联记录的属性时。优点是简单易用，Rails官方推荐，能大幅减少查询次数；缺点是如果关联的数据量太大（比如每个订单关联100个商品），预加载会占用太多内存，这时候需要结合其他技巧优化。注意事项：includes只预加载你需要的关联，不要预加载不需要的关联，否则会浪费内存和查询时间。
2.2 只查需要的字段：用select减少数据传输
很多时候你不需要整行数据，比如只需要用户的昵称，却把整个users表的所有字段都查出来，数据库要传输更多数据，速度就会变慢。用select可以指定只查你需要的字段，减少数据传输量。
示例如下：
# 错误写法：会查users表的所有字段
orders = Order.includes(:user, :product).order(created_at: :desc).limit(100)
orders.each do |order|
# 只需要user的nickname，却查了user的所有字段
user_nickname = order.user.nickname
end
# 正确写法：用select指定需要的字段
# 注意：关联表的字段要写清楚表名，避免和主表字段重名
orders = Order.includes(:user, :product)
.select('orders.id, orders.created_at, users.nickname, products.name')
.order(created_at: :desc)
.limit(100)
orders.each do |order|
# 这里的nickname和name是预加载的指定字段，没有多余数据
user_nickname = order.user.nickname
product_name = order.product.name
end
应用场景：当你只需要关联表的少数几个字段时。优点是减少数据库和应用服务器之间的传输数据量，提升速度；缺点是如果后续代码需要用到关联表的其他字段，会报错，因为这些字段没有被查询出来。注意事项：select指定的字段要包含关联表的主键，否则ActiveRecord无法正确关联数据，比如上面的例子中，users表的id字段会被自动包含吗？不会，所以如果要确保关联正确，最好在select里加上关联表的主键，比如users.id, users.nickname。
2.3 批量处理大数据：用find_each替代each
当你需要处理大量数据（比如10万条订单）时，直接用each遍历会把所有数据一次性加载到内存，很容易导致应用服务器内存溢出，甚至崩溃。find_each会把数据分成批量（默认1000条），每次只加载一个批量的数据到内存，处理完再加载下一个批量，大大降低内存占用。
示例如下：
# 错误写法：一次性加载所有订单到内存，容易内存溢出
Order.all.each do |order|
# 处理订单，比如计算金额
order.update(amount: order.amount * 1.1)
end
# 正确写法：用find_each批量处理，每次加载1000条
# 可以通过batch_size参数修改批量大小，比如batch_size: 2000
Order.all.find_each(batch_size: 1000) do |order|
# 处理订单，内存只占用1000条数据的大小
order.update(amount: order.amount * 1.1)
end
应用场景：批量处理大量数据（比如数据迁移、批量更新、导出数据）时。优点是大幅降低内存占用，避免内存溢出；缺点是如果处理过程中需要用到全局数据（比如所有订单的总金额），find_each需要额外处理，因为每次只处理一个批量。注意事项：find_each默认按主键排序，所以如果你的查询需要特定排序，要注意调整，另外批量大小要根据服务器内存调整，太大还是会内存溢出，太小会增加查询次数。
2.4 避免不必要的查询：用exists?替代count
很多开发者会用count来判断一个记录是否存在，比如判断用户是否有未处理的订单，错误的写法是Order.where(user_id: 1).count > 0，但count会查所有符合条件的记录数，而我们只需要知道有没有至少一条，这时候用exists?更高效，它会生成更简单的SQL，比如SELECT 1 FROM orders WHERE user_id = 1 LIMIT 1，数据库不用统计数量，只要找到一条就返回。
示例如下：
# 错误写法：统计所有符合条件的订单数量，浪费性能
if Order.where(user_id: 1).count > 0
puts "用户有未处理订单"
end
# 正确写法：用exists?判断是否存在，更高效
if Order.where(user_id: 1).exists?
puts "用户有未处理订单"
end
应用场景：只需要判断记录是否存在，不需要知道具体数量时。优点是生成的SQL更简单，数据库处理速度更快；缺点是如果确实需要知道数量，就不能用exists?。注意事项：exists?可以和其他查询条件结合，比如Order.where(user_id: 1, status: 'pending').exists?。
三、调优后的效果对比
我们用一个实际场景来对比调优前后的效果：假设要获取1000个订单，每个订单显示用户昵称和商品名称。
- 调优前：N+1查询，总共1+1000+1000=2001次查询，总耗时约3000ms（3秒），内存占用约20MB。
- 调优后：用
includes预加载，总共3次查询，总耗时约200ms（0.2秒），内存占用约5MB。 可以看到，调优后的速度提升了15倍，内存占用减少了75%，效果非常明显。
四、调优的注意事项
- 不要为了调优而调优：只有当实际出现性能问题时再调优，不要提前优化，否则会增加代码的复杂度。
- 先定位问题再调优：用Rails的
rails server -e development启动开发环境，访问页面后，查看日志里的SQL查询，找到慢查询的具体原因，再针对性调优。 - 注意索引：如果查询条件经常用到某个字段（比如
user_id、created_at），要给这个字段加索引，否则即使调优了ActiveRecord的查询，数据库处理SQL的速度还是慢。比如给orders表的user_id加索引：
# 迁移文件中添加索引
class AddIndexToOrdersUserId < ActiveRecord::Migration[7.0]
def change
add_index :orders, :user_id
end
end
- 不要过度依赖预加载：如果关联的数据量太大，预加载会占用太多内存，这时候可以考虑分页，比如一次只加载10条订单，而不是100条。
五、文章总结
ActiveRecord的数据库查询性能调优，核心是围绕“减少查询次数”、“减少数据传输量”、“减少内存占用”这三个点展开。从最常见的N+1查询问题入手，用includes预加载关联数据，用select指定需要的字段，用find_each批量处理大数据，用exists?判断记录是否存在，这些技巧都是简单易用且效果明显的。
调优的过程不是一蹴而就的，需要先定位问题，再针对性调整，同时要注意平衡性能和代码的可读性。对于不同基础的开发者来说，只要理解了这些技巧的核心逻辑，就能轻松应用到自己的项目中，解决大部分的数据库查询性能问题。
评论
围绕“Ruby on Rails中ActiveRecord的数据库查询性能调优实战技巧”参与讨论