私は現在、大学で「パフォーマンス評価」のコースを受講しており、現在、PHP および MySQL データベース サーバーで CPU 使用率をテストする課題を行っています。httperf を使用してカスタム トラフィックを作成し、vmstat を使用してサーバーの負荷を追跡します。INSERT と DELETE (個別に実行) の両方で、PHP サーバーへの 3000 接続を実行しています。
数値は、DELETE 操作が INSERT 操作よりもはるかに CPU を集中的に使用することを示しています — なぜだろうか?
最初は、インデックスを再作成する必要があり、データをディスクに書き込む必要があるため、INSERT にはより多くの CPU 使用率が必要だと思っていました。
少なくとも InnoDB を使用すると (そして、彼らがこれについて教えてくれることを願っています)、外部キーがなくてもより多くの操作ができます。挿入はおおよそ次のとおりです。
削除は次のことを行います。
そのため、挿入ではなく削除に 2 倍の作業が必要になります。削除には、今後のすべてのバージョンで削除済みとしてマークする必要があるため、これらの 2 つの書き込みが必要ですが、それを参照するトランザクションが残っていない場合にのみ削除できます。InnoDB は完全なブロックのみをディスクに書き込むため、ブロックの変更ペナルティは一定です。
DELETE では、ディスクへのデータの書き込み、インデックスの再計算、および最初に削除しようとしているレコードを見つけるための一連の論理比較も必要です。
削除には、思ったよりも多くのロジックが必要です。その程度はスキーマの構造に依存します。
ほとんどの場合、レコードを削除するとき、サーバーはそのレコードへの依存関係を外部キー参照としてチェックする必要があります。簡単に言えば、システム テーブルのクエリで、このテーブルへの外部キー ref を持つテーブル定義を検索し、削除するレコードを参照するレコードをこれらのテーブルのそれぞれから選択します。サーバーがカスケード削除を行うか、単にエラーを返すかに関係なく、計算時間が数桁増加しました。
セルフバランシングの内部データ構造も再編成する必要があり、インデックス ツリーの空になったブランチを削除するためにインデックスを更新する必要がありますが、これらは挿入操作に対応するものがあります。