WordPressデータベースの深淵：InnoDB断片化の真実と、サービスを止めない最適化戦略
WordPressのデータベース、特に `wp_posts` や `wp_postmeta` は、単なるデータの入れ物ではない。これらは「書き込み頻度」と「読み取り要求」が極端に混在する、最も負荷の高い領域だ。
多くのエンジニアが「データベースが重い」と感じる時、その原因の多くはインデックスの不整合やクエリの非効率性にあるが、物理層におけるInnoDBの断片化（Fragmentation）を見落としているケースが後を絶たない。
今日は、なぜ断片化が起きるのか、そしてそれを「サービスを止めることなく」解決する技術的アプローチを解説する。
—
1. なぜInnoDBは「穴」だらけになるのか
MySQL（InnoDB）のデータは、B+Tree構造で管理されている。ページ（デフォルト16KB）単位でデータが格納されるが、ここで「断片化」が発生するメカニズムは以下の通りだ。
- ページ分割（Page Split）: 行の更新や挿入時、ページに空きがなくなると、InnoDBはページを分割し、新しいページを作成する。
- 削除の痕跡: `wp_postmeta` 等で頻繁に行われる `DELETE` 処理は、その領域を物理的に即座に解放するわけではなく、「空き領域（ガベージ）」としてマークする。
結果、論理的にはデータが詰まっているように見えても、物理層では隙間だらけの「スカスカなテーブル」が完成する。これがディスクI/Oを増大させ、バッファプールのヒット率を低下させる最大の要因だ。
2. サービスを止めない「オンライン」最適化の設計パターン
通常、MySQLの `OPTIMIZE TABLE` はテーブルをロックする。数百万レコードある `wp_postmeta` でこれを実行すれば、サイトは数分から数時間のダウンタイムに陥るだろう。
そこで我々エンジニアが取るべきは、「ALTER TABLE … ALGORITHM=INPLACE, LOCK=NONE」 戦略だ。
実践：WP-CLIを活用した安全な最適化設計
PHPの `wpdb` を介して実行するのではなく、バックエンドのコンテキストから独立したプロセスとして実行するのが、本番環境での鉄則である。
/
- データベースの断片化を解消する非同期バックグラウンド処理クラス
- 運用上の注意:
- 1. サーバーのディスク空き容量が、最適化対象テーブルの約2倍あることを確認する
- 2. 実行時は長時間実行クエリとして扱われるため、適切なタイムアウトを設定する
/
class DatabaseOptimizationEngine {
/
- オンラインでの最適化を実行する
- MySQL 5.6以降のオンラインDDL機能を利用
/
public static function optimize_table_online(string $table_name) {
global $wpdb;
// サービス停止を防ぐため、ロックをかけずに再構築する
// ALGORITHM=INPLACE: テーブルをコピーせず、物理構造を再構築する
// LOCK=NONE: 読み取り/書き込みのブロックを一切発生させない
$sql = “ALTER TABLE {$wpdb->prefix}{$table_name}
ENGINE=InnoDB,
ALGORITHM=INPLACE,
LOCK=NONE”;
$result = $wpdb->query($sql);
if ($result === false) {
error_log(“Optimization failed: ” . $wpdb->last_error);
return false;
}
return true;
}
}
3. なぜこの設計が「堅牢」なのか
コードレビューで見かける「全テーブルを一度に最適化しようとするスクリプト」は、地雷原を歩くようなものだ。本番環境で堅牢な設計を維持するには、以下の思想が不可欠である。
1. 段階的実行: 巨大なテーブルを一度に最適化するのではなく、`wp_options`（軽量）→ `wp_posts`（中量）→ `wp_postmeta`（重量）と優先度とリソース消費量を分けて実行する。
2. インデックスの再構築: `OPTIMIZE TABLE` は自動的にインデックスを再構築するため、B+Treeの深さが均一化される。これにより、キー検索のパフォーマンスが劇的に向上する。
3. レプリケーションへの配慮: マスターで実行した `ALTER` はスレーブへ同期される。スレーブ側で負荷が跳ねないよう、実行間隔を空けるキューイング設計が必須だ。
4. エンジニアへのアドバイス：計測なき最適化は罪である
最適化を行う前と後で、必ず以下のクエリを実行し、改善幅を定量化せよ。
— 断片化率（Data_free）を確認するクエリ
SELECT
table_name,
round(data_length / 1024 / 1024, 2) ‘data_mb’,
round(data_free / 1024 / 1024, 2) ‘free_mb’
FROM information_schema.tables
WHERE table_schema = ‘your_db_name’;
`free_mb` が `data_mb` の20%を超えている場合、それはシステムの「負債」である。
WordPressを単なるCMSとして扱うのは卒業しよう。これは立派なアプリケーション基盤であり、データベースの物理構造を掌握した者だけが、高トラフィック下でも安定して稼働する堅牢なシステムを構築できる。
設計に妥協するな。コードは常に論理的で、かつ物理的な挙動を意識したものであれ。それが伝説的なエンジニアの流儀だ。