SQLのupdate文の想定時間について

Question

結構な件数の重たいUPDATE文を実行しようと思ってるのですが、おおよそ何分かかるのか知りたい場合、クエリは実行しないで想定時間を知る方法って無いですか？

MySQLでSQLの実行時間のみを調べる

このような記事を見つけましたが、実行してしまうので、、

もし無いとしたら、dbをコピーしてそちらで一度実行させるのが手っ取り早いですか？？

ご教授宜しくお願いします。

Answer 1

UPDATE 後、COMMITしないでROLLBACKすれば済むことでは？

Comments

[awazon78]

下の方もおっしゃっていましたが良さそうですね！

Answer 2

トランザクションでロールバックすれば良いのでは？

追記

処理時間を気にする＝性能改善の対象
質問の本題とは逸れますが、この回答へのコメントから、少なくとも一括コミットでの性能改善余地がありそうに感じたので
MySQLに大量のデータを入れるときに最適な方法は？

そもそもはupdateの発行回数を減らすようにするのが最善ですけど、それを行うには影響が大きいでしょうね。

Comments

[yambejp]

負荷の調査のために負荷をかけて大丈夫なのでしょうか？
その間当該レコードをロックするんですよね？

[sazi]

トランザクション制御については、バイナリログの話ですね。
新たにロックする/しないの話は生まれないと思うのですが？

所要時間調査で、COMMIT/ROLLBACKの差異は気にする程の割合では無いと思っています。

[awazon78]

なるほど。。
START TRANSACTION;

UPDATE A_TABLE
SET NAME = 'aaa'
WHERE ID = 1;

UPDATE A_TABLE
SET NAME = 'bbb'
WHERE ID = 2;

~~~省略

ROLLBACK;

って事ですね。

ロックしないのであれば良いですね！

[tacsheaven]

逆に auto transaction になっていると、1件の update が実際には start transaction -> update -> commit になってしまうので、実際の「update 単独」の速度ではなくなります。

[sazi]

@tacsheavenさん

> おおよそ何分かかるのか知りたい
ということでもあるので、処理時間を気にする程度の処理であるなら、トランザクション制御の部分に要する時間の比率は少ないと思うのです。

[tacsheaven]

なんですが、1件ごとコミットだと、連続updateしたときの差って結構でかいですから……バッチ処理で100件単位とかで start transaction -> commit ってやるだけで性能目に見えて変わりますからねえ……

[sazi]

確かにこのコメントに書かれたようなものだと、違ってきますね。
あくまで単独のSQLでのUPDATEを想定した回答でしたから。

[awazon78]

処理時間を知りたい　＝　実行日に朝何時に出社しようかなとおもったので。。
普段あまりsqlをがっつり触ることが少ないので勉強になります。お二人ともありがとうございます

Answer 3

負荷が気になるというだけであれば
where句の条件次第ですが
limitを与えて何度かに分けて処理してみては？
場合によってはprocedureを用意すれば良いでしょう

Answer 4

同じSQLは環境状況により同じ結果（実行時間）が返ってくるとは限らないので、実際にSQLを実行するしかないはずです。
どうしても本番に手を入れたくないというのでしたらご提示のようにテスト用DBを作ってそちらで試すのが良いのではと。