なぜALGORITHM = COPYをALGORITHM = INPLACEよりも優先するのですか？
MySQL 5.6からオンラインDDLが導入されて以来、 ALTER TABLE コマンドはオプションでALGORITHM=INPLACEまたはALGORITHM=COPYが指定されています。 オンラインDDLの概要 は、デフォルトでは、可能な限りINPLACEが使用され、は暗黙的に（ INPLACEアルゴリズムはCOPYアルゴリズムよりも安価であることをこれまでまったく述べていません。
だから私はALGORITHM=COPY、ALTER TABLEステートメント？
はい、COPYを指定できる場合がありますが、それはパフォーマンス以外の理由によるものです。
MySQLが新機能を導入したことを理解することが重要です-オンラインDLLバージョン5.6での処理。オフライン処理は削除されませんでした。したがって、これらの2つのモードを区別する必要があります。
一部の操作は、オフラインモードでのみ機能します。インプレースで実行できる、または実行できないDDL操作のリストについては、表15.10「 DDL操作のオンラインステータスの概要 」を参照してください。
オンラインモードとオフラインモードでの操作の動作は少し異なるため、互換性の理由から「古い」モードを選択できます。
いくつかの例（詳細を提案してください）：
MySQL 5.6以前に作成されたInnoDBテーブルは、テンポラル列（
DATE、DATETIMEまたはTIMESTAMP）を含み、ALTER TABLE ... ALGORITHM=INPLACEを使用して再構築されていないテーブルのALTER TABLE ... ALGORITHM=COPYをサポートしません。この場合、ALTER TABLE ... ALGORITHM=INPLACE操作はエラーを返します。ADD PRIMARY KEYのCOPY mode句は、NULLをそのデータ型のデフォルト値（INTの場合は0、varcharの場合は空の文字列）にサイレントに変換しますが、IN_PLACEは変換しません。
ALGORITHM = COPY句を使用すると、主キー列にNULL値が存在しても操作は成功します。データが静かに変更されるため、問題が発生する可能性があります。
COPYを選ぶもう1つの理由：
ALGORITHM = COPYまたはold_alter_table = 1を指定する操作。特殊なシナリオでの正確な下位互換性が必要な場合に、テーブルをコピーする動作を強制します。
MySQLマニュアルでは実際のシナリオについては触れていませんが、いくつか想像できます。例えば。開発者はALTER INDEX操作中にテーブルがロックされることに依存していたため、テーブルは読み取り専用または完全にロックされ、インデックスの再構築中に静的テーブルを読み取るプロセスが存在します。
@Stolegがおそらく最良の答えを持っていますが、ここに別のものがあります。開発者が残したのは、知識に基づく推測です=COPYに深刻なバグがあった場合に備えて、エスケープハッチとして=INLINE。これにより、ユーザーは新機能が壊れていてもALTERを使い続けることができます。
私はこのようなものを見てきました（フラグ、sql_mode、my.cnf設定など）長年にわたって。新しいリリースの意図は明らかに、新しい、より良い、機能を引き出すことです。
最適化フラグはこのカテゴリに分類されますが、前のアクションにとらわれる理由はさらに多くあります。オプティマイザは常に「間違っている」ことがあります。可能性が多すぎます。