データベーススキーマは、アプリケーションの成長と要件の変化に応じて常に進化します。伝統的なスキーマ変更はダウンタイムを必要とし、ユーザー体験を損ない、売上を失わせます。MySQL の Online DDL は、データベースを稼働させたままスキーマ変更を実行できるようにすることで、この問題を解決します。
3 つのアルゴリズム: INSTANT、INPLACE、COPY
MySQL はスキーマ変更に 3 つのアルゴリズムを使い、それぞれ性能特性と対応操作が異なります。
INSTANT: 最速の選択肢
INSTANT はテーブルメタデータだけを変更し、瞬時に変更を適用します。データコピー不要、リソース消費は最小、レプリケーションとも完全に整合します。一方で、対応する操作は限定的です — デフォルト値付きのカラム追加、enum の変更などに限られます。
INPLACE: バランス型
INPLACE は一時的なコピーを作らずにテーブルを直接変更します。実行中も並行する DML 操作 (INSERT、UPDATE、DELETE) が可能で、INSTANT より多くの操作 (索引作成、カラム削除など) をサポートします。代償としてリソース消費は大きくなります。
COPY: 伝統的な方式
COPY は新テーブルを作成し、すべてのデータをコピーし、テーブルを入れ替えます。最遅ですが、データ型の変更を含むすべてのスキーマ変更に対応します。INSTANT と INPLACE が使えないときの最終手段として使います。
操作対応表
| 操作 | INSTANT | INPLACE | COPY |
|---|---|---|---|
| カラムの追加 | ✅ * | ✅ | ✅ |
| カラムの削除 | ✅ * | ✅ | ✅ |
| カラムのリネーム | ✅ * | ✅ | ✅ |
| データ型の変更 | ❌ | ❌ | ✅ |
| セカンダリ索引の追加 | ❌ | ✅ | ✅ |
| 索引の削除 | ❌ | ✅ | ✅ |
| 主キーの追加 | ❌ | ✅ * | ✅ |
| 主キーの削除 | ❌ | ❌ | ✅ |
| 外部キーの追加 | ❌ | ✅ | ✅ |
条件付きの対応あり。詳細は MySQL ドキュメント を参照。
主な制限
リソースへの影響: INPLACE 操作は CPU、メモリ、I/O を大きく消費し、混雑したサーバーでは DB 性能に影響することがあります。
レプリケーション遅延: 最大の制限はレプリケーションの挙動です。プライマリで 3 時間かかる INPLACE 操作は、各レプリカで 3 時間にわたってレプリケーションを止め、巨大な遅延を生みます。
ロックの問題: 「オンライン」とは言っても、メタデータロックが他の DDL 操作や一部の DML をブロックすることがあります。
INSTANT の対応範囲が限定的: データ型変更、索引追加、主キー変更などの複雑な操作の多くは INSTANT では対応できません。
ベストプラクティス
賢く選ぶ: 可能なら INSTANT、必要なら INPLACE、最終手段として COPY。
先にテスト: スキーマ変更は本番を模したステージングで必ず検証する。
性能を監視: 操作中の CPU、メモリ、I/O 使用量を確認する。
サードパーティツールも検討: 複雑なマイグレーションや厳しい可用性要件には、gh-ost や pt-online-schema-change がより細かい制御とレプリケーション対策を提供する。
レプリケーションを織り込む: レプリケーション構成では、各サーバーで個別に変更を実行するか、外部ツールで遅延を避けることを検討する。
結論
MySQL Online DDL はスキーマ進化のための有用な機能を提供しますが、その制限を理解することが肝心です。INSTANT 操作は対応していれば理想的、INPLACE 操作はリソース計画が要、ミッションクリティカルな環境ではネイティブ機能とサードパーティツールを組み合わせることで、安全と効率のバランスが最良になることが多いでしょう。