ActiveRecord查询性能优化：如何分析并提升慢查询效率？

1. 查看查询执行计划，定位瓶颈 #

直接在数据库中执行带EXPLAIN的SQL，明确查询的执行路径：

EXPLAIN SELECT Count(responded_at) / Count(*) 
FROM   `user_placements`
WHERE  `user_placements`.`deleted_at` IS NULL
       AND ( `user_placements`.`notification_sent` IS NOT NULL )
       AND `user_placements`.`user_id` = 1 

重点关注这几个核心字段：

• type：如果显示为ALL，说明是全表扫描，这是性能慢的核心原因；若为ref或range则表示用到了索引。
• key：查看实际命中的索引，确认是否匹配预期。
• rows：数据库预估的扫描行数，数值过大意味着过滤效率低下。

2. 构建覆盖索引，减少回表开销 #

你现有的索引要么是单独的user_id，要么是placement_campaign_id + user_id的联合索引，无法覆盖当前查询的所有过滤条件和统计字段。直接创建一个覆盖索引，把查询涉及的所有字段都包含进去：

CREATE INDEX idx_user_placements_user_deleted_notified_responded 
ON user_placements (user_id, deleted_at, notification_sent, responded_at);

这个索引能让数据库直接从索引中获取所有需要的数据，无需回表查询原表，大幅提升查询速度。

3. 核查数据量与数据分布 #

先统计该用户符合条件的记录总数：

SELECT COUNT(*) 
FROM user_placements 
WHERE user_id = 1 
  AND deleted_at IS NULL 
  AND notification_sent IS NOT NULL;

如果结果是几十万甚至上百万条，即使有索引，实时计算比率也会较慢。这种情况可以考虑：

• 数据归档：将历史旧数据迁移至单独的历史表，缩小主表的数据规模。
• 缓存结果：用Redis等工具缓存该比率值，比如定时（如每日）计算更新，或在数据变更时同步更新缓存，避免每次实时计算。

4. 微调查询逻辑（可选） #

COUNT(responded_at)/COUNT(*)的逻辑没问题，但可以尝试等价写法，观察数据库是否有不同的优化策略：

SELECT SUM(CASE WHEN responded_at IS NOT NULL THEN 1 ELSE 0 END) / COUNT(*) AS response_rate
FROM user_placements
WHERE user_id = 1 
  AND deleted_at IS NULL 
  AND notification_sent IS NOT NULL;

另外，ActiveRecord代码可调整得更清晰（不影响性能）：

UserPlacement.notified.where(user_id: 1).select('COUNT(responded_at) / COUNT(*) AS response_rate')

5. 检查数据库服务器配置 #

若上述优化后仍无明显改善，排查数据库服务器的基础配置：

• 比如MySQL的innodb_buffer_pool_size是否足够大，能否将常用数据缓存至内存，减少磁盘IO次数。
• 服务器的CPU、内存资源是否被其他进程占用，导致数据库无法全力处理查询请求。

内容的提问来源于stack exchange，提问作者jordan