MySQL INSTANT DDL を本番投入する前に観測したこと

A 観測の前提

ALTER TABLE のたびに数時間止まる、というのは過去の話 —— と 公式ドキュメント は言います。 実際、ALGORITHM=INSTANT で済む操作は、テーブルのメタデータを書き換えるだけで完了します。 ただし「すべてのカラム追加が INSTANT で済む」とは書かれていません。書かれていないことのほうが、実運用では重要です。

以下の3点を、観測対象として固定します。カラム順序の制約、追加カラム数の上限、 そして 後続 OPTIMIZE TABLE が暗黙にフルリビルドへ降格する瞬間。

B INSTANT DDL が落とす罠

最初に踏みやすいのは、カラム追加の 位置指定 問題です。 MySQL 8.0.29 まで、ADD COLUMN ... AFTER existing_col は INSTANT で行えませんでした。 テーブル末尾への追加であれば INSTANT、途中挿入は IN-PLACE に降格 —— という静かなトラップがあります。

INSTANT は速さの保証ではない。

—— アルゴリズムの選択肢を増やしたという「設計の自由度」の話。

次に、information_schema.innodb_tables の INSTANT_COLS カウンタです。 ここに溜まったカラム数が、テーブル定義上の上限（行フォーマットや page size に依存）に近づくと、次の DDL が黙って IN-PLACE 経路に切り替わります。 「速いはずの操作が突然遅くなった」ときの第一容疑者です。

1— INSTANT で溜まった “論理的にしか存在しない” カラム数の確認
2SELECT name, n_cols, instant_cols
3FROM   information_schema.innodb_tables
4WHERE  instant_cols > 0
5ORDER BY instant_cols DESC
6LIMIT 20;

3つ目は、OPTIMIZE TABLE の意味の変質です。 INSTANT 追加されたカラムを物理的に書き戻すのは、結局のところ次のテーブル再構築時です。 そのタイミングは予測可能でなければいけません。

C 計測の組み立て

プロダクションでは、DDL の所要時間そのものよりも「後続 SELECT のレイテンシ分布が変わるか」のほうが重要です。 Akira のチームでは、以下のような順序で観測を組みました。

1. DDL 直前直後の P95 / P99 を 5 分粒度で記録
2. SHOW ENGINE INNODB STATUS の BUFFER POOL AND MEMORY を5分おきに保存
3. information_schema.innodb_metrics で dml_inserts の変化点を追う
4. 再現用の シャドウ環境 で同じ DDL を投げ、メトリクスの差分を取る

ここまでやって、ようやく「INSTANT で問題ない」と言えます。 ドキュメント1ページの結論を、観測で4本足にする作業です。

D 結論と次にやること

INSTANT DDL は 使えます。ただし、INSTANT_COLS カウンタの定期観測と、 計画的な OPTIMIZE のタイミング設計をセットにしてください。 「速さ」ではなく「予測可能性」を選んだ操作だと理解すれば、運用上の判断が変わります。

次は同じ枠組みで、PostgreSQL の ALTER TABLE ... ADD COLUMN ... DEFAULT の挙動差分を観測する予定です。 → 続編の準備ノートを Works に置いています。