# Adding an Includes Clause to ActiveRecord and Watching the Joy Flow

DevFeed: [Adding an Includes Clause to ActiveRecord and Watching the Joy Flow](<https://devfeed.tech/articles/adding-an-includes-clause-to-activerecord-and-watching-the-joy-flow-28245.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/rails/2019/11/18/adding-an-includes-clause-to-activerecord-and-watching-the-joy-flow.html>)

Author: Fuzzygroup

Published: 2019-11-18T00:00:00Z

Content type: tutorial

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [bug](<https://devfeed.tech/topics/bug.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [activerecord](<https://devfeed.tech/tags/activerecord.md>), [bug](<https://devfeed.tech/tags/bug.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rails](<https://devfeed.tech/tags/rails.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

This article explains how repeated ActiveRecord queries created an N+1 query problem and shows that adding .includes(:metric_type) to the query fixes the issue by loading the associated metric types together.

## Source excerpt

I've written in the past about watching your SQL queries stream by in the Rails console and how seeing, well, stupidity / things that look wrong can help guide you to things you need to find. Here's an example I witnessed recently: habit = Habit.find(2) habit.total_this_month Metric Load (2.5ms) SELECT metrics.date_created_at, metrics.int_val, metrics.float_val, metrics.metric_type_id FROM metrics WHERE metrics.habit_id = 2 AND (date_created_at >= '2019-11-01') AND (date_created_at <= '2019-11-30') MetricType Load (3.3ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (38.1ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (17.0ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (40.3ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (2.7ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (1.3ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (3.2ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (5.2ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (252.9ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (11.2ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (7.4ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 MetricType Load (1.6ms) SELECT metric_types.* FROM metric_types WHERE metric_types.id = 1 LIMIT 1 According to the bug tracker where I logged, this it was logged 5 days ago (so on November 12). And if you could the number of metric_type queries above, the total is 12. This is date ordered stuff so it is pretty obvious that what's happening is that metric_type query is getting executed once per day. Here's the