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
設定など)長年にわたって。新しいリリースの意図は明らかに、新しい、より良い、機能を引き出すことです。
最適化フラグはこのカテゴリに分類されますが、前のアクションにとらわれる理由はさらに多くあります。オプティマイザは常に「間違っている」ことがあります。可能性が多すぎます。