開発を担当しています。普段Railsを使って開発されている方であれば、N+1問題に悩まされた経験は大抵の方がおありではないでしょうか。bulletを使うとN+1なクエリを発見してくれ、さらに、具体的にここにincludesを追加しなさいと指摘までしてくれるので大変助かります。eager_loadについて改めて調べてまとめてみることにしました。)includesの挙動については正しく知っておきたいincludesの挙動について、「preloadとeager_loadをよろしく使い分けしてくれるもの」と認識しているRailsエンジニアは結構いるのではないでしょうか?そういったエンジニアの方の中には、先日の私のようにN+1問題の対策で深く考えずに「includesつけとけばOKでしょ。ほらbulletのN+1のアラート止まったし。」という方もいらっしゃるのではと思っています。「とりあえずincludes」で、データが少ないうちは問題にならなくてもデータが増えてきた時に問題が顕在化する事がよくあります。loading)、N+1問題の解消策となります。joinで取得しキャッシュします。includesはどうやって、eager_loadとpreloadを使い分けしているのか、見ていきます。メソッドによって判定されていることが分かります。trueのときにtrueとなります。しているアソシエーションが存在すればtrueとなります。falseの時にpreload_valuesにincludes_valuesが足しこまれてpreload処理がされていきます。eager_loadされるといったことにはなりません。association_bともにpreloadされるか、eager_loadされるかのいずれかとなります。ある勘違いのひとつかなと思います。eager_loadの使い分けについてケース・バイ・ケースです。アソシエーションについてはpreloadすることを基本線としています。includesはクエリが状況によって変わってコントロールしずらいので基本使わないようにしています。joinでまとめて取得した方が効率的な事が多いと思っています。queryを踏みやすいためpreloadを基本にするのが良いと思っています。has_manyアソシエーションをeager_loadするとスロークエリが発生しやすいレコードのリスト取得の際にはページング等でレコード件数の絞り込みをする事が多いと思いますが、このレコード件数の絞り込みが、has_manyアソシエーションがeager_loadされていると大変になってきます。joinしたSQLが返すレコードはUserについて重複を含んだものになってくるため絞り込みが難しい形となります。メソッドの以下の部分で、対処しています。