からのデータはどのようにしているのそれぞれ200〜300万行、と生産システム上のテーブルからデータを削除するハンドルは、潜在的にデータの100K-1M（複数MEDIUMTEXTフィールドを持って最善を尽くすxmlを含む）？おそらく、不要になったレガシーデータであるため、約3/4の行が削除されます。は/生産MySQLの
私はトランザクションごとに管理可能なチャンクへの削除を分割するplsqlスクリプトを書いていましたが、すぐにいっぱいになるbinlog（データベースは複製されています）に問題があり、IIRC 。
私の現在の考え方は、ちょうどいっぱいビンログを回避し、それらを時間をかけてクリアしましょうするために、毎日十分に除去して、各データベースに対して毎日実行するのcronタスクのいくつかの種類を登録することです。より良い選択肢はありますか？
削除される行のxmlフィールドがすべて削除される前にnullに設定されていた場合、その行をただちに削除するのと比べて、binlogのサイズが縮小されますか？
私はおそらくそれについてあなたが記述の道を行くと思います。
スクリプトはチャンクで古いレコードをクリアするためにcronで実行され、必要に応じて、レプリケーションスケジュールに応じて、必要に応じて、あなたはバイナリログを消去することができます。
レプリケーションを使用している場合は、スレーブがまだ使用されていないことを確認するまで、マスター上の古いバイナリログファイルを削除しないでください。たとえば、あなたの奴隷3日以上の背後に実行されない場合は、一日一回、あなたがマスター上でmysqladminフラッシュ・ログを実行してから三日以上古いすべてのログを削除することができます。手動でファイルを削除することもできますが、PURGE BINARY LOGSを使用することをお勧めします.PURGE BINARY LOGSはバイナリログインデックスファイルを安全に更新します（日付引数を取ることもできます）。 14.4.1.1項「PURGE BINARY LOGS構文」を参照してください。
As per Docs
これをやって、データを削除するのに2週間しかかかりませんでした。スケジュールは、binlogがそれ自体を消去するのに十分な時間を持っていたほど十分に緩いものでした。 2週間にわたる15分ごとの2kエントリは250万を超えています。そのため、小さなバッチは実際には驚くほど大量のデータに蓄積されます。 – user467257
このbtwを実行しているmysqlのinnodbテーブルからほぼ100ギガバイトのデータを削除しました（同様のデータベースの複数のインスタンス）。その後の実行「の表を最適化する」ことを忘れないでくださいまたは、それがファイルシステムからスペースを再利用しません - しかし、あなたはもしinnodb_file_per_tableセットを持っている必要があります、またはあなたがスペースを再利用することはできません。 – user467257
これはdba.stackexchange.comにある必要があります。 – Veve