MySQL スキーママイグレーションのベストプラクティス

スキーマ変更はソフトウェア開発の通常運用です。カラムが追加され、データ型が変わり、索引が生まれては消えます。しかし MySQL では、計画が甘いと簡単な ALTER TABLE でもクエリをブロックし、レプリカを遅らせ、ダウンタイムを招きます。

本ガイドでは、MySQL のスキーママイグレーションを管理する実践的な方法を紹介します — シンプルで、実本番環境で効く MySQL の挙動に焦点を当てます。

コアとなるベストプラクティス#

ここで述べる考え方は、データベースマイグレーション全般に広く当てはまります。MySQL 固有の挙動を考える前の信頼できる土台です。

スキーマ変更をたどれるようにする#

データベースがどう進化したかをチームは明確に記録する必要があります。 Git でも、マイグレーションツールでも、整理された Changelog でもよいですが、要点は次の通りです。

これにより、隠れた本番変更や環境ドリフトを防げます。

小さく、増分的で、後方互換なステップを使う#

より安全なアプローチは、よく知られたパターンです。

1. Expand — 何も削らずに新しいカラムやテーブルを追加する
2. Migrate — データをバックフィルし、アプリケーションロジックを更新する
3. Contract — すべてが安定した後に古いフィールドを削除する

Contract ステップは通常数日後に行われます。カラム削除は不可逆だからです。チームはシステムのすべてが新しい構造を使い、実トラフィックで問題が出ないことを確認してから踏み切ります。

チェックとワークフローを自動化する#

自動化はミスを減らし、一貫性を高めます。

• SQL レビュールール: 危険な SQL を実行前に捕まえる。
• CI チェック: マイグレーションスクリプトに自動テストと静的チェックを走らせる。
• ステージング検証: 現実的なデータでマイグレーションが正しく動くことを確認する。
• 環境プロモーションの一貫性: Dev → Test → Prod で同じ順序でマイグレーションを適用する。

これらは開発から本番までの予測可能な道筋を作ります。

知っておくべき MySQL の挙動#

MySQL にはスキーママイグレーションに直接影響するいくつかの特性があります。早いうちに理解しておけば、後から驚かずに済みます。

• テーブル全体を再構築するスキーマ変更がある — 一部の ALTER TABLE 操作はテーブルの新しいコピーを作り、処理を遅くしたり書き込みをブロックする。

• メタデータロックがクエリをブロックする — スキーマ変更は進行中のクエリの完了を待ち、待っている間に後続のクエリをブロックする。

• 大きな変更はレプリカ遅延を生む — 大きな ALTER や重いバックフィルはレプリカを遅らせ、読み込みやフェイルオーバーに影響する。

• 一部の MySQL 機能は変更しづらい — ENUM の変更、JSON 索引、大きなテーブルの FOREIGN KEY などが典型例。

MySQL 向けの実践的なマイグレーションワークフロー#

このワークフローは、MySQL の挙動を念頭に開発者が実際にやっていることを反映しています。

1 変更を慎重に計画する#

SQL を書く前に、影響を理解する。

• 操作はテーブルを再構築するか？
• 本番でテーブルはどれくらい大きいか？
• マイグレーションをブロックする長時間クエリはあるか？
• レプリカはどう反応するか？
• 作業を小さく安全なステップに分割できるか？

数分の計画で、後の多くの問題を防げます。

2 シンプルで予測可能なマイグレーションスクリプトを書く#

良いマイグレーションスクリプトは理解しやすくレビューしやすいものです。

• 1 スクリプトにつき 1 つの論理変更
• 明確で説明的な命名
• スキーマと重いデータ更新を混ぜない
• 必要ならステップに分ける (例: カラム追加 → バックフィル → コード更新)

古い MySQL バージョンはデフォルト値付きカラム追加でテーブルを再構築することが多いため、操作を分けるとリスクが減ります。

3 実影響を意識してマイグレーションをテストする#

テストでは正しさと性能の両方を見ます。

• まず Dev、次に Staging で実行
• 本番サイズに合わせたステージングデータを使う
• マイグレーション所要時間を計測
• レプリカが遅れていないか観察
• 変更後のテーブルでアプリケーションの挙動をテスト

ローカルでは一瞬に見える変更も、実データでは数分以上かかることがあります。

4 注意深く、観察しながらデプロイする#

デプロイ中は次を行う。

• マイグレーションを順番に各環境へ昇格
• DDL を実行する前にブロックしているクエリを確認
• 監視:
  • メタデータロック待ち
  • スロークエリ
  • レプリカ遅延

MySQL の DDL はトランザクション化されていないため、スキーマ変更のロールバックは通常できません。リスクを抑えるには:

• 問題を素早く修正するためにロールフォワードのマイグレーションを使う
• 信頼できるバックアップを保ち、リストア手順をテストしておく
• 可能ならデータマイグレーションを可逆にする

明確な復旧計画を伴う慎重なロールアウトが、デプロイをずっと安全にします。

ツールとゼロダウンタイムの選択肢#

MySQL のマイグレーション課題を回避するために存在するツールがあります。

pt-online-schema-change#

シャドーテーブルを作り、データを徐々にコピーすることでロックを軽減する。大規模で混雑するテーブルに有用。

gh-ost#

トリガではなくバイナリログを使い、書き込みの多いワークロードでもうまく機能する。 大規模なオンラインスキーマ変更で、より安全なことが多い。

ネイティブ MySQL Online DDL#

MySQL 8.0 はより多くの高速操作をサポートする。それでも、想定外の挙動を避けるためのテストは必要。

マイグレーションフレームワークとワークフローツール#

これらはスキーマ変更のバージョニング、順序、実行を管理するのに役立ちます。

• Flyway バージョンを追跡し、スキーマ変更を順番に適用する。

• Liquibase 宣言的なチェンジセットを使い、ロールバックロジックと整理されたマイグレーションワークフローをサポートする。

• Bytebase スキーマ変更、SQL レビュー、環境プロモーションのためのワークフローを提供し、GUI ベースの changelog と GitOps モードの両方をサポート。 大きなテーブルでのより安全なオンラインスキーマ変更のために gh-ost とも統合する。

結論#

安全な MySQL スキーママイグレーションは、MySQL の挙動を理解し、明確で一貫したワークフローに従うことから生まれます。小さな変更、適切なテスト、ロックとレプリケーションへの基本的な認識を組み合わせれば、チームははるかに少ないリスクと不確実性でスキーマを更新できます。