MySQLで未知の書き込みが多すぎます

Question

私の生産環境にはMySQLデータベースがあります。約4億3000万行のうち1億9000万行が使用されていなかったので、これらの行を範囲、夜間、それは昼間の私のアプリのパフォーマンスに影響を与えたからです。

私の監視アプリケーションで見ると、100％IOが表示されています。最大値は書き込み（12-30MB/s）です。 （400-500書き込み/秒） しかし、私がプロセスリストをチェックしているときに、私はINSERTまたはUPDATEクエリやロールバックを見つけることができません。

可能性のある問題は何か、またはどのようにMySQLで書いている可能性がある隠しクエリを見つけることができますか。

（IOTPで、私はその書き込み操作のみのmysqldによって行われている見つかっ）

もう一つ、私は80メガバイト/ sのiotopの中で書く見ることができますが、私は、ディレクトリのサイズを確認していたときに/ 、私はどんなディレクトリサイズでも上昇を見ません。

Answer 1

ゆっくり戻って...待ってください。

InnoDBは、各DMLクエリでテーブルスペースファイルの実際のデータを変更しません。

変更を実際にメモリに書き込んだ後、redo logが有効に「生きて」安全にディスクに保存されますが、実際のデータ（テーブルスペース）ファイルにはまだ適用されていません。その後、InnoDBは変更をバックグラウンドでデータファイルと同期させますが、他のクエリは表スペースとログの内容を組み合わせて使用​​して、現在「正式な」表データに含まれているものを判別します。もちろん、これは過度の単純化ですが、MVCCは必然的に論理データのスーパーセットではありませんが、必然的にスーパーセットであることを意味します。

これはあなたが今見ているものの説明になる可能性が非常に高いです。

フリー/使用ディスク領域は変更されません。これらの行の削除を完了すると、実際には表スペースファイル内のスペースが未使用としてマークされるだけなので、意味があります。彼らは成長したり縮んだりしないでください。

これを修正しようとする誘惑に抵抗し、サーバーを再起動しないでください。できるだけ良い結果が得られるのは、やるべきことが残っているからです。

SHOW ENGINE INNODB STATUSは解釈するのに練習を要しますが、パズルの別の鍵になる可能性があります。

Answer 2

削除操作はまだ行われていますか？ DELETEは非常に遅く、多くの書き込みを生成します。新しい同一のテーブルを作成し、KEEPに保存する行をコピーして、本番表の内容を直接削除するのではなく、本番表で切り替えてください。

DELETEが既に終了しているとあなたが実行している他のクエリがあると思われる場合は、あなたが数秒間クエリログを有効にして実行されるクエリを参照することができます

TRUNCATE TABLE mysql.general_log; 
SET GLOBAL log_output = 'TABLE'; 
SET GLOBAL general_log = 'ON'; 
SELECT SLEEP(10); 
SET GLOBAL general_log = 'OFF'; 

その後にmysql.general_logから選択10秒のスリープ中に実行されたクエリを確認します。