なぜDBから引くときに1000件ずつchunkingするのか、説明できますか - Lambdaカクテル

MySQLやPostgreSQLといったRDBMSからデータを引いてくるとき、扱うデータの規模によっては、1000件ずつLIMITをかけて順に引いていくということがある。 以前slow queryが出たらよくやっていたのを思い出して、ふとこのあたりってどういう根拠があってやっているのだっけ、自分が知っている他に効能があったりするのかな、と思ってSlackに書き込んだところ、同僚の id:onk に教えていただいた。その内容に加えて軽く調べた内容をまとめてみる。 Web系の話です。みなさまの知見がありましたら教えてください。 TL;DR 刺さる*1から 刺さったら困るから あたりまえ 詳細 もともとSlackに書いた原文は以下の通り(MySQL前提で書いているけどPostgresといった他のRDBMSにも適用できる話。): DB引くとき、Perl時代(？)によく1000件単位でchunkin

[threetea0407]

MySQL に食わせる IN の件数に上限はないけど、一定数超えると index 効かなくなるというオプティマイザの挙動があります

[iouri]

こういうのDBと処理系側で良き様にやってくれよと思いながら、境界値テストこまごまと書いてた覚え。

[kagehiens]

行単位処理が可能なブロックを重ねたようなバッチ処理の場合、最大消費メモリを押さえる工夫がされていないと、アホみたいなサイズのバッファを確保する必要が発生して、複数走らせたときにメモリがヤバいからでは。

[strawberryhunter]

まず"刺さる"は聞いたことが無いな。お前んとこの社内用語だろ。／トランザクションが終わるまでselectした行は分離レベルによって相応のロックがかかる。デッドロックは即座にエラーになるから普通のロック解除待ち。

[shoh8]

“クエリなどが重すぎて応答が帰ってこなくなることをいうジャーゴン” 刺さる人 / スタックする、パンクする、サチる、ビジる

[lyiase]

クエリ実行自体を割込的な意味合いで「刺す」とは言うことがあるけど、返ってこなくなることを「刺す」って言うのは始めて聞いた。はてなってそんな謎な言葉使うんだ。

[dot]

"刺さる"は古い用語だね。まぁ古参エンジニアが居なかったり、そこから伝わってないと知らなのは仕方ない。別に今わざわざこの用語使わなくてもコミュニケーションに困らないし。

[tmatsuu]

デッドロックはMyISAMの経験則では。InnoDBはロック粒度が細かいのでゼロではないものの素のSELECTでデッドロックが発生する状況は少ない。結局のところ全件取得でメモリ不足によるスワップアウトがI/Oに刺さるんだと思う。

[tomoakinagahara]

コメントが面白い

[murasuke]

1000件ずつLIMITするにしても、orderbyがあると最後まで読まないとデータ返せない（そのためにindexをつけとけばいいけど）から、早くなるの転送だけじゃね？と思ったり。場合によるのでは？

[deep_one]

ぶっちゃけシステムが強力ならいらない。／というか、今時のシステムでもそんなに刻むんだ…

[nemoba]

IO待ちとメモリ消費の話すればよいのに刺さるつうふんわり言葉にしてない仮説

[xlc]

fetchを知らないバカだから。/ https://x.com/koba0367/status/1831898327690178615

[daishi_n]

生SQL書くのがパフォーマンスの点でもねー

[toaruR]

リソース的に必要なケースが有るのは自明だけど、chunkって処理中に件数が変わったら境目が重複したり取り損ねたりしないんかな？っていうかするよね（´－｀）論削ごとbyidで引けってことかな

[fn7]

ふんわり。

[nakag0711]

ページ単位で表示するのではない場合の話？本当のクライアントカーソルがないからその代わりにということかな

[bopperjp]

これって、select の話？なんで select の話に「デッドロック」が出てくる？ マジでわからないんだけど/あー、普通のロックの話か/「刺さる」は使うなぁ。リクエストレイテンシの急上昇症状で。どこかに引っかかるイメージ

[prograti]

メモリが理由の場合が多い気がしますね。特にunit of work系のORMを使っている場合はメモリを大量に消費しますし

[ene0kcal]

「IOに刺さる」とは？？もしかしてOSレベルでの、ディスクやメモリのアクセス回数がデータ量に対して最小にならない事を言ってますか？例えば抽出1000件だとアクセス1回、1001件だと2回になるというような。

[rryu]

PerlでMySQLでワーカープロセスが前提なら、結果セットが全部メモリに乗るのでプロセスが太るのを防ぐかDB接続を占有されるのがつらいのいずれかだと思う。それによって速くなる要因は基本的には無い。

[onesplat]

大抵の場合はメモリに一度に載せたくないからじゃないのかね

[turanukimaru]

1000件を超えたらどこかで詰まることを心配する、と言ったほうが良い。例えば次のINに使うには多すぎるとかメモリに展開すると100MBになるとか自治体の帳票印刷リクエストが10000件発行され1時間占有するとか…

[imash]

それだけのデータを処理するのは大体バッチ処理よな

[tmdtky]

アプリケーション側でキャッシュメモリのサイズに収まるようにすると速いからだと思ってたわ

[masatomo-m]

生SQLを書いたことがあったりCURSORとかを知ってる老人には説明できないことの方が？？って感じなのだが、ORMしか触ってないと説明できなくなるのもまあわかる（Webアプリ系老人

[buzztaiki]

全部舐めるならフルスキャンの方が早い場合もあるし場合によりけりな気もする。

[paradoxparanoic]

そんな大量のデータが必要になる時点で何かが間違ってる可能性。分離レベルによっては取りこぼしや2度読みが発生するし