Q&A
> どうしても使いたい理由が私には思いつきません。
SQLの発行回数が減ることで高速になります。
知りたいこと
SQLのバルクインサートは、PHPなどの実コード上で利用して良いのか？
この疑問に至った理由
どこかで聞いた記憶があるがそのソースが見つからず、「記憶違いかどうか」を確認したいので、
お知恵をお貸しいただけると嬉しいです。
記憶
バルクインサートはDBロックが掛かるので、実コードでは使わない方が良い
バルクインサートは高速ですが、DBロックが掛かるので、実コード上ではあまり使わないほうが良く、
遅くともinsert文を一つずつ実行していくほうが良い。
バルクインサートは、直接値を入れるときやバッチ処理で使う。
と、本か何かで知った記憶があります。
この記憶は間違いなのでしょうか？それとも正しいのでしょうか？
ご存知の方がいらっしゃいましたら、ご教示いただけますと幸いです。
回答4件
0
ベストアンサー
PHPということなので、MySQLと仮定して。
MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために
MySQL(InnoDB)でのDeadLock調査
MySQLのトランザクション分離(ISOLATION)レベルが、REPEATABLE READ（デフォルトがREPEATABLE READ）では、ファントムリード回避のためにネクストキーロックによるインデックス挿入時のロックが発生する可能性があります。
ファントムリードが問題にならない作りなら、ISOLATIONレベルをREAD COMMITEDにすれば発生はしないようです。
投稿2018/12/27 02:56
編集2018/12/27 04:09総合スコア25173
0
単純なテーブルロックの話ではなく、デッドロックについてだと思います。
(バルクインサート デッドロックで検索すると、具体的な説明があると思います)
また、実処理(実サービス)上でInsertを発行する場合、基本的にトランザクション管理下で作業をすることになると思いますが、どういったエラーが発生した際にどこまでデータを反映するか、といったことは、とても関心の高い機能設計になると思います。
例えば、禁則文字が1レコード(の1カラム)だけ入っていたせいで、その他のレコードまですべてなかったことにするのか、それともエラーのあったレコードだけ登録するか、等。
例えばECサイトで複数の商品の入ったカートを購入遷移に移そうとするとき、1つの商品が在庫切れだからと「購入できません」となるとまずいので、在庫のある商品だけを購入遷移に流す、など。(普通はUI含めて回避する話ではありますが、いい例が思いつかなかったので。)
なので、どうしても使いたい理由がなければ使わない方がいいです。
そしてどうしても使いたい理由が私には思いつきません。
投稿2018/12/27 02:46
総合スコア5405
サービス上で執り行われるInsertが、千件万件といったまとまりで行われるとは考えにくいので、どうしても使いたい理由にはなりにくいんじゃないかと。(数十件程度なら誤差レベルでは)
少ない件数しか扱わない時に、敢えてbulk insertを使う必要性って事ですね。
成程。
ご回答有り難うございます！！
> 単純なテーブルロックの話ではなく、デッドロックについてだと思います。
これだー！！
デッドロック！ありがとうございます！！かなりスッキリしました＞＜
何かで聞いた記憶はあるものの、あまり理解せずに終わっていまい、いざ知識が必要な時にソースを提示できず、
すごくもやもやしておりました。。。
sazi様とkunai様のやり取りを見、
「件数が少ないときにはバルクインサートは利用しないほうがいい」という理由がわかりました。
ありがとうございます！
0
バルクインサートはDBロックが掛かるので、実コードでは使わない方が良い
インサートについては更新・削除よりも他の作業に対して影響がでにくいので
あまり気にしなくてよいでしょう。
バルクインサートが原因のDBロック（テーブルロック？）もないと思います
もちろんトランザクションにおいてrollbackする可能があるならあまり大量のデータを
やり取りするのは効率的ではないかもしれません
１データ毎の流し込みをすると１アクション毎にセッションの接続・開放が発生し
オーバーヘッドが大きいです。
大量データについては基本的にバルクインサートするのが妥当でしょう。
(適正な単位があるので環境によっては分割が必要)
投稿2018/12/27 02:34
総合スコア114769
ご回答有り難うございます！
なるほど、DBロックは発生しないのですね…
勘違いしておりました。
> 大量データについては基本的にバルクインサートするのが妥当
こちらありがとうございます！
0
実コードとはいってもあくまでDBにSQL文を届けるだけなので関係ないと思います。
要はPHPの処理を「formタグから送るか」、「Ajaxから実行するか」の違いと似たようなものかと。
フレームワークでバルクインサート用のTraitを作った という例もあるようですし。
処理時間が長くなったり、1つ1つ実行しているということはinsert文の数だけDBアクセスが発生していて
WebサーバーにもDBサーバーにも負荷がかかるのでそちらの方が問題としては大きいです。
投稿2018/12/27 02:22
編集2018/12/27 02:24
総合スコア80850
ご回答有り難うございます！
> 処理時間が長くなったり、1つ1つ実行しているということはinsert文の数だけDBアクセスが発生していて
WebサーバーにもDBサーバーにも負荷がかかるのでそちらの方が問題としては大きい
なるほど、完全に記憶違いでしたね。
ありがとうございます。
ちなみにバルクインサートは何件くらいのinsertから採用するのが適切なのでしょうか？
んー。
件数ではないと思います。
極端に言えば、１カラムしかないテーブルと100カラムあるテーブルでは１レコード挿入時の負荷が違いますし、テーブル構成にもよります。どれくらいのサイズのデータが入るとか。
タイムアウトしてしまうようになったときやサーバー側で負荷増大を感知した際に、改善策のひとつとして挙げるくらいでしょうか。
他の回答者の意見も待って参考にしてみてください。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/01/03 13:02
2019/01/03 14:00 編集
2019/01/06 02:40