最近、これを使用してデータベースから200万行以上を削除しました（ユーザーが存在しなくなったユーザー履歴を一掃したかったのです）。私は Django の簡単な履歴を使用しています。
active_ids = User.objects.values_list("id", flat=True)
User.history.filter(~Q(id__in=active_ids)).delete()
これには約 5 分かかり、必要なすべての行が削除されました。ただし、操作を実行する前のテーブル サイズは約 900 MB でした。行を削除した後でも、まだ 700 MB あります。予想をはるかに超えています。さらに調べてみると、このテーブルの index_length のサイズは依然として 424 MB と大きいようです。実際に落ちたということはないと思います。
このインデックスのサイズは減りましたか? User モデルには、id、username、email などのいくつかの db_indices があります。
データベース管理を変更することをお勧めします。PostgreSQL はより大きなデータ ストレージ用に構築されているため、PostgreSQL に変更できます。または、ビッグデータを試すこともできます。データが本当に非常に大きくなる場合に備えて。後で分析に使用できるため、データの削除はあまりお勧めしません。
たとえば、django と cassandraDB を試すことができます。https://github.com/r4fek/django-cassandra-engine
これらは、django の問題ではなく、mysql の問題です。
mysql や postgresql などの RDBMS では、インデックスがある場合、一括挿入、削除、更新は常に遅くなります。それが獣の本性です。
高速化する最善の方法は、インデックスを調べて、クエリで使用されていないインデックスを削除することです。すべてのインデックスを保持する場合は、キー バッファー サイズを最適化します。
postgresql の通常のユーザーとして、これが mysql から postgreql に切り替える十分な理由ではないことを保証します。全体像と他のすべての要因を見ると、間違いなくpostgresqlの方が優れていますが、この問題を決定要因にしないでください.
ハードディスクの空き容量が本当に不足している場合を除き、そのままにしておいてください。テーブルが再び大きくなると、そのスペースはデータベースによって再利用されます。200 万の新しいレコードを追加すると、ディスクの使用量がまったく増加していないことがわかります。
あなたが本当にスペースに追われているなら。テーブルを最適化します。この操作にも時間がかかります。