https://b.hatena.ne.jp/entry/s/qiita.com/ham0215/items/e0f6ebb59009100d8abb N+1 それは諸悪の根源！パフォーマンスの敵！！ 見つけたらすぐに撃退すべき悪しき存在です！！！ と思われている方が多いと思います。 実際その通りで、ネットで調べてもN+1を解消するノウハウが溢れています。 ... https://b.hatena.ne.jp/techtech0521/20240329#bookmark-4686349774256441090 2024-03-29T12:37:46Z あとで読む https://b.hatena.ne.jp/nishitki/20200531#bookmark-4686349774256441090 2020-05-31T09:43:16Z https://b.hatena.ne.jp/atomicmap/20200531#bookmark-4686349774256441090 2020-05-31T03:55:49Z https://b.hatena.ne.jp/takasago08/20200531#bookmark-4686349774256441090 2020-05-31T03:45:05Z https://b.hatena.ne.jp/Makeneko/20200531#bookmark-4686349774256441090 扱う数が多くなると、インスタンス生成のコストもネックに。結局、メモリ使用量や時間などを計測しないと、問題ないことの理由付けとして弱いかも。 2020-05-31T02:37:36Z https://b.hatena.ne.jp/jksdaba/20200531#bookmark-4686349774256441090 2020-05-31T01:33:06Z https://b.hatena.ne.jp/decoy2004/20200531#bookmark-4686349774256441090 2020-05-31T00:13:40Z https://b.hatena.ne.jp/Tomosugi/20200531#bookmark-4686349774256441090 2020-05-30T23:06:26Z https://b.hatena.ne.jp/honma200/20200531#bookmark-4686349774256441090 2020-05-30T22:20:50Z あとで読む https://b.hatena.ne.jp/chiku-san/20200531#bookmark-4686349774256441090 2020-05-30T20:41:17Z あとで読む https://b.hatena.ne.jp/nukosan555/20200531#bookmark-4686349774256441090 2020-05-30T18:17:56Z https://b.hatena.ne.jp/hisato20/20200531#bookmark-4686349774256441090 2020-05-30T17:43:34Z あとで読む https://b.hatena.ne.jp/peketamin/20200531#bookmark-4686349774256441090 2020-05-30T16:09:46Z https://b.hatena.ne.jp/tanavel/20200531#bookmark-4686349774256441090 2020-05-30T15:46:44Z あとで読む https://b.hatena.ne.jp/asayamakk/20200530#bookmark-4686349774256441090 2020-05-30T14:51:41Z https://b.hatena.ne.jp/stokiwa/20200530#bookmark-4686349774256441090 2020-05-30T14:36:23Z あとで読む https://b.hatena.ne.jp/azuma1252/20200530#bookmark-4686349774256441090 2020-05-30T13:36:08Z https://b.hatena.ne.jp/masatotoro/20200530#bookmark-4686349774256441090 “N+1はあくまでパフォーマンス改善の1つの手” 2020-05-30T12:45:56Z https://b.hatena.ne.jp/vuy/20200530#bookmark-4686349774256441090 ORMを滅したうえで2waySQLに乗り換えたほうがいい。 とくにORMの仕様にあわせたDB設計してるとことか、ORMと心中したいのかと思う。 2020-05-30T12:43:20Z https://b.hatena.ne.jp/kaido/20200530#bookmark-4686349774256441090 2020-05-30T12:18:55Z あとで読む https://b.hatena.ne.jp/wkwkhautbois/20200530#bookmark-4686349774256441090 Ruby/ActiveRecordはよく知らないけど、メモリ消費量の前に、余計なデータを扱うことによるDB内での読込時間とDB-AP間の転送時間に触れた方が良さそう。前の方が述べてるように、遅延読込の意図が無ければjoinとlimit使いたい。 2020-05-30T11:45:23Z https://b.hatena.ne.jp/sirosirocat/20200530#bookmark-4686349774256441090 2020-05-30T11:32:04Z あとで読む https://b.hatena.ne.jp/hbKOT/20200530#bookmark-4686349774256441090 2020-05-30T11:02:01Z performance DB https://b.hatena.ne.jp/yarukinasu/20200530#bookmark-4686349774256441090 2020-05-30T09:48:57Z https://b.hatena.ne.jp/n314/20200530#bookmark-4686349774256441090 1000件のうち5件取得を、まずDBじゃなくてプログラムでやろうと思う思考がよく分からん…。自分ならlimitつけたlateral join書いちゃうけど、rails的には生sqlは悪ということだろうか。 2020-05-30T03:05:54Z https://b.hatena.ne.jp/Hiro_Matsuno/20200530#bookmark-4686349774256441090 2020-05-29T23:37:45Z https://b.hatena.ne.jp/lugecy/20200529#bookmark-4686349774256441090 2020-05-29T13:54:28Z article webdev programming rails