ベストアンサー

内容を削除したときのパフォーマンス

2014/02/09 23:46

プログラム初心者です掲示板のレスを削除フラグを立てて後からメンテの時に削除するようにしました将来行う削除する方法なんですが、daleteで行を削除するのではなく、カラムに入っている内容を削除しただけでもパフォーマンスはよくなりますか？残った行はid番号だけにする予定です例えば100ＭＢの容量が70ＭBくらいになるイメージですそれともメンテの時に行を削除したほうがいいでしょうか？大体の経験からの判断でいいのでよろしくおねがいします

flash0
お礼率97% (297/306)

MySQL
回答数3
ありがとう数3

みんなの回答 （3）
専門家の回答

質問者が選んだベストアンサー

ベストアンサー

いけだひろし（@ike-2000）
ベストアンサー率53% (69/129)

2014/02/10 10:47 回答No.3

古い人間なので現状にあっていなかも知れませんが経験より。このシステムはオンラインで、月次にバッチでメンテが出来るような環境であると想定しました。また、DBMSの物理的なキャッシュなどは考慮していません。 (1)削除フラグを使うこの目的は「消しちゃったけど戻したい」が主たる目的です。この条件でなければ、また、大量の削除でなければ、オンラインでのdeleteでも良いと思います。レコードが減る分、バックアップが楽になります。 (2)カラムに入っている内容を削除する nullか空白でupdateするということですよね。インデックスにレコードが残るという観点ではメリットはないでしょう。検索において、削除されたレコードは取得されないので関係ないと思います。 (3)オンラインでの削除 deleteすることによってレコードが減ればそれだけインデックスが軽くなり(なれば)検索は早くなる可能性があります。ただし、これは非常に稀です。 (4)性能「削除フラグを使う」でdeleteで良いと書きましたが実は「削除フラグ」という考え方は正しいかも知れません。インデックスが張られているでしょうからこれらも更新の対象になります。昔(10年前)では、I/Oは大体10ms/1件といった感じです。これは、update、delete、insert、インデックス更新が該当します。例えば、3個のインデックスがあるテーブルで考えてみます。「削除フラグ」を使う場合、削除されたレコードを読み込まないために、すべてのインデックスに削除フラグが関連するはずです。削除フラグを立てて他の列を空白等でupdateする場合、 [1]select　for　update　;1行確定 [2]update　;1行更新 [3]インデックス更新　;インデックス1 [4]インデックス更新　;インデックス2 [5]インデックス更新　;インデックス3 の5回のI/Oが発生します。約50msかかる計算です。また、deleteでは、 [1]select　for　update　;1行確定 [2]delete　;1行削除 [3]インデックス更新　;インデックス1 [4]インデックス更新　;インデックス2 [5]インデックス更新　;インデックス3 の5回のI/Oが発生します。約50msかかる計算です。オンラインでの性能面から見るとどちらも同じようになります。結局はインデックス更新にも引っ張られますので、オンラインでの処理ではどちらでも良いということになります。オンライン以外の性能ではdeleteした方がレコード少なくなるだけメリットが有るように感じます(レコードは少ないに越したことな無いです)。長々と書きましたが、私はユーザ要件によって削除フラグを使うか否かを決めていました。間違えた削除を戻す必要がないならdeleteで良いと思います。メンテについてですが、容量に応じて色々な方法が考えられます。件数が多くなるようでしたらファイルに吐き出して、削除レコードを削除し、LOADERで入れ込むことも考えられます。 MySQLはロックリソースが必要でしょうから(詳しく知りません)、想定件数で仕組みを考えるべきと考えます。

質問者

お礼 2014/02/10 23:57

回答ありがとうございます詳しい解説ありがとうございますいろいろ勉強になりました deleteを直接やってみたんですがphpmyadminから見るとオーバーヘッドが発生していました updateだと発生していませんでしたみなさんの貴重な意見を聞いて、バックアップをとってから削除できるテーブルの行は削除しようと思いますありがとうございました