ランダムアクセスファイルを更新する代わりにファイルに追加すると、より高速になります。
ファイルに追加すると、断片化が発生しないのではないかと思っていました。MySQLなどのデータベースは、最初にログベースのファイルにデータを追加し、最終的にデータを実際の「テーブル」に保存することを読みました。
ファイルに追加してファイル サイズが変更された場合、断片化が発生し、ランダム アクセス ファイルで書き込みを使用した場合と同じ問題が発生しないのではないかと考えていました。
(まず、これを整理しましょう。ファイル システム レベルの断片化は、実際には Microsoft ファイル システムのみの問題です。断片化に関する以下のコメントは、Microsoft ファイル システムのみに適用されます。質問は Linux ファイル システムとは事実上無関係であるため)
MySQL で 2 つの異なるメカニズムが混在しているようです。
バイナリ ログには、テーブルの作成操作やテーブル データの変更など、データベースの変更を記述する "イベント" が含まれています。
本当にログです。これは、すべてのトランザクションの最後に順次書き込まれ、新しいトランザクションがコミットされるにつれて無期限に増加します。完全を期すmax_binlog_size
ために、ログが に到達すると、新しいファイルが最初から作成されることに言及しましょう。 logrotate
このファイルは、あなたが説明したように断片化する可能性があります。これは、常に大きくなるためです。ただし、この断片化は集中的に使用されるわけではないため、パフォーマンスへの影響はほとんどありません。
不完全なトランザクションによって書き込まれたデータを修正するために、クラッシュ リカバリ中に使用されるディスク ベースのデータ構造。(...) 予期しないシャットダウンの前にデータ ファイルの更新を完了しなかった変更は、自動的に再生されます[したがって、その名前]。
このログは、ログというよりもバッファーです。このログは、固定サイズの一連のファイルで構成され、起動時に一度割り当てられます。データベースへの変更は、まずこのバッファ ゾーンに順番に書き込まれ、次に実際のデータ ファイルに転送されます。
このバッファは、サイズが固定されているため、実際には断片化の影響を受けません。断片化は他の要因によって常に発生する可能性がありますが、とにかく最小限に抑える必要があります。
PS: 私は常に、実稼働環境で MySQL のホスト OS として Windows を使用することを避けています。とにかく、Windows でのパフォーマンスは、Linux に比べてまだ少し遅れています。
PPS:基になるファイル システムに関係なく、テーブルには最適化が必要です