バイナリログからの復元が非常に遅いのはなぜですか？
バイナリログが有効になっているMySQL5.5サーバーと、バイナリログを収集し、1日1回mysqldumpで完全なデータベースダンプを生成するバックアップスクリプトがあります。ダンプとビンログからのデータベースの復元をテストしたところ、後者の方が桁違いに遅いことがわかりました。
具体的には：
mysql dbname < dbdump.sqlを使用した92.8MBのデータベースダンプからの復元には、3分26.526秒かかりました。mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbnameを使用してダンプした後からすべてのバイナリログを復元するには、38分10.090秒かかりました。 binlogファイルの合計サイズは56.8MBで、mysqlbinlogからの出力のサイズは66.4MBでした。- Binlogsがカバーするイベントの後に取得された（93.2 MB）ダンプから復元するだけで、上記の2つの手順を組み合わせると、2分15.406秒かかりました。
今回の格差は正常ですか？それを減らすために何かできることはありますか？
バイナリログとは何かを理解する必要があります。バイナリログには、記録されてから発生したすべてのクエリ（STATEMENT形式）または行の変更（ROW形式）が保存されます。だから、あなたのコマンド：
mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbname
基本的にこれらのほぼ30のbinlogの間にサーバーに対して発生したすべての挿入、更新、および削除をシリアルに実行します。そのため、バイナリログからのリカバリは、ポイントインタイムリカバリ（最後のバックアップ以降の最新の変更のリカバリ）にのみ役立ちます。
アプリケーションの時間を短縮するためにできることがいくつかあります。たとえば、データベースの耐久性と整合性の制約を一時的に減らす（いつでも手順を再生できるため）-innodb_flush_log_at_trx_commit、無効にするバイナリログ、二重書き込みなど-またはROWバイナリログを使用してみてくださいのみ。これにより、ディスクのサイズが大きくなる可能性がありますが、適用が速くなります。
または、適用する必要のあるbinlogの数を減らすより頻繁な完全バックアップを作成し（完全バックアップのサイズは正確に大きくない）、xtrabackupなどのツールを使用して実際の増分バックアップまたは差分バックアップを作成することもできます。 -または災害復旧のために遅延スレーブを使用します。これは、mysqldumpとmysqlbinlogの両方が論理的な方法でデータを回復する-物理バックアップが場合によっては高速になる場合がある、特に完全回復の場合に発生します。
もちろん、特定の問題もある可能性があります。たとえば、LOAD DATAステートメントの再生が思ったよりも遅いことが時々あります。
目標は何ですか？目標がシステムを回復するためのパスを持つことである場合は、レプリケーションの使用とスレーブの使用を検討してください。スレーブは通常、マスターとの分までです。これは、あなたが不平を言っている93分よりもはるかに優れています。