InnoDBの深淵：WordPressデータベース断片化の物理的解明とゼロダウンタイム最適化
WordPressのデータベース、特に `wp_postmeta` や `wp_options` は、高頻度な更新と削除の繰り返しによって、InnoDBのページ構造内に「物理的な負債」を蓄積させる。これは単なる容量の問題ではなく、B+Treeインデックスの再構成効率や、OSレベルでのI/Oレイテンシに直結する。
本稿では、InnoDBのページ管理メカニズムから紐解き、サービスを停止させずに断片化（Fragmentation）を解消するアーキテクチャ設計を解説する。
—
1. なぜInnoDBは断片化するのか：ページ・デフラグのメカニズム
InnoDBはデータを「ページ（通常16KB）」単位で管理する。レコードが削除されると、その領域は「空きスペース」としてマークされるが、物理的なファイルサイズは即座に縮小しない。
- ページ分割（Page Split）: インデックスの挿入時にページが埋まると、InnoDBはページを半分に分割し、新たなレコードの場所を作る。このとき、元のページには空間が生じる。
- 断片化の正体: 削除によって生じた断片的な空き領域（External Fragmentation）は、ディスクI/Oの効率を低下させる。ランダムアクセスが増大し、バッファプール（Buffer Pool）のヒット率を悪化させる。
WordPressの `wp_postmeta` は、meta_keyによる検索とmeta_valueの頻繁な更新が繰り返されるため、この断片化が最も顕著に現れる領域である。
—
2. 禁断の `OPTIMIZE TABLE` とオンライン最適化
MySQLにおいて `OPTIMIZE TABLE` は、本質的には `ALTER TABLE … ENGINE=InnoDB` を実行し、テーブルを再構築する操作だ。古いバージョンではこれがテーブルロックを引き起こした。
しかし、現代のMySQL/MariaDBにおいて、InnoDBは `ALGORITHM=INPLACE` をサポートしている。これにより、サービスを停止せずに（オンラインで）テーブルの再構築が可能だ。
実行戦略のベストプラクティス
直接 `OPTIMIZE TABLE` を叩くのは大規模テーブルではリスクがある。以下の手順で `pt-online-schema-change`（Percona Toolkit）の挙動を模した、安全な再構築を推奨する。
— 1. 現在の断片化状況を確認
SELECT table_name, data_free / 1024 / 1024 AS free_mb
FROM information_schema.tables
WHERE table_schema = ‘your_wp_db_name’;
— 2. オンライン最適化の実行（ロックを回避）
— インプレースでテーブルを再構築し、断片化を解消する
ALTER TABLE wp_postmeta ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE;
注意：`LOCK=NONE` は、DDL操作中にDML（INSERT/UPDATE）をブロックしないことを意味する。しかし、実行時に一時的なリソース消費が増大するため、低負荷帯での実行が鉄則である。
—
3. WordPressの内部から断片化を防ぐ：アーキテクチャ的アプローチ
データベースのクリーンアップを繰り返すだけでなく、断片化の「発生源」を抑制するのがエンジニアの責務である。
不要なメタデータ生成の抑制
WordPressの自動保存（Autosave）やリビジョン管理は `wp_postmeta` を肥大化させる主因だ。`wp-config.php` で制御せよ。
/
- 物理構造の保護：リビジョンの制限
- データベースの断片化を物理的に防ぐための最小限の設定
/
define( ‘WP_POST_REVISIONS’, 5 ); // リビジョンを制限
define( ‘AUTOSAVE_INTERVAL’, 300 ); // 自動保存の間隔を広げ、更新頻度を抑える
データベースの物理設計の改善
`wp_postmeta` が数ギガバイトを超える場合、垂直分割を検討すべきだ。頻繁に読み書きされるメタデータと、アーカイブ的なメタデータを別のテーブルへ切り出す（あるいはカスタムテーブルを定義する）のが、スケーラビリティを確保する唯一の道である。
—
4. パフォーマンス測定：内部の挙動を観測する
最適化の前後で、Buffer Poolの効率がどう変化したかを計測せよ。
実行前後のキャッシュヒット率を比較
mysql -e “SHOW ENGINE INNODB STATUS\G” | grep -A 10 “BUFFER POOL AND MEMORY”
最適化成功の指標は、`Free buffers` の安定と、`Pages read` の減少である。物理レイアウトが最適化されることで、OSのページキャッシュとInnoDBのバッファプール間のヒット効率が劇的に向上する。
—
結論：システムに「呼吸」させる
WordPressを単なるCMSとしてではなく、一つの「ランタイムエンジン」として捉えるならば、データベースはメモリの延長線上にある。断片化を放置することは、メモリリークを放置することと同義だ。
`ALGORITHM=INPLACE` による動的な再構築は、システムの血流を正常化させる外科手術である。ただし、この手術を行う前に、必ずバックアップ（バイナリログの確認と論理バックアップ）を忘れてはならない。
大規模なトラフィックを捌くWordPressにおいて、データベースの物理構造を掌握することは、パフォーマンスチューニングの終着点であり、スタートラインでもある。さあ、今すぐ `information_schema` を覗き、システムの「肥満度」を測定することから始めよ。