【実務・中級編】WordPressデータベースの断片化を解消するオンラインテーブル最適化とInnoDBのメカニズム – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressの深淵：InnoDBの断片化を制し、データベースを極限まで最適化する

WordPressのパフォーマンスを語る際、多くのエンジニアが `wp_posts` や `wp_postmeta` のクエリ効率に終始する。だが、真のコントリビューターは、「データがどのように物理的に配置されているか」というストレージエンジンの挙動にまで目を光らせる。

特に高頻度で更新や削除が行われるサイトにおいて、InnoDBの「断片化（Fragmentation）」は、インデックススキャン速度を徐々に蝕む静かなる癌だ。今回は、WordPressのデータベースにおける断片化のメカニズムを解剖し、プロダクション環境で安全にこれを解消する戦術を伝授する。

—

1. なぜInnoDBは断片化するのか？

InnoDBにおいて、データはB+Tree構造のインデックス内に格納されている。`DELETE` 文が発行された際、InnoDBは即座にその領域を物理的に解放するわけではない。

ページ内の穴: 削除されたレコードの領域は「再利用可能な空き領域（Free Space）」としてマークされるが、物理的なファイルサイズは縮小しない。
フラグメンテーション: 更新・削除の繰り返しにより、ページ内に「飛び地」のような空きが発生し、データの局所性が失われる。これにより、ページ読み込みの効率が悪化し、Buffer Poolのキャッシュヒット率が低下する。

WordPressの `wp_postmeta` は典型例だ。リビジョン機能やプラグインによるメタデータの一時保存を繰り返すことで、このテーブルは物理的に膨れ上がり、クエリのI/Oコストを増大させる。

—

2. オンライン最適化の真実：`OPTIMIZE TABLE` の挙動

MySQLの `OPTIMIZE TABLE` は、InnoDBにおいては内部的に `ALTER TABLE … FORCE` を実行し、テーブルを再構築する。

かつてはテーブルロックが発生し、サービス停止を招く禁忌とされていたが、現代のMySQL 5.7/8.0およびMariaDBでは、Online DDLとして機能する。つまり、ロックを最小限に抑えながらインデックスの再構築が可能だ。

実務で使うべき「最適化」の設計パターン

WordPressから直接 `OPTIMIZE TABLE` を発行するのは推奨しない。DB接続のタイムアウトや、実行中の高負荷がアプリケーションの安定性に影響するからだ。代わりに、WP-CLIを介したバッチ処理として実装し、メンテナンスウィンドウ内に制御実行するのが唯一の「正解」である。

プロダクション環境用：安全な最適化スクリプト

以下のコードは、WP-CLIのコマンドとして実装し、テーブルの断片化率を判定して必要最小限の最適化のみを行う、保守性の高い設計例だ。

カスタムWP-CLIコマンド: データベースの断片化解消

使用法: wp db-optimize run –threshold=20

if ( ! defined( ‘WP_CLI’ ) || ! WP_CLI ) return;

class DB_Optimize_Command {
/

@subcommand run
@synopsis [–threshold=]

/
public function run( $args, $assoc_args ) {
global $wpdb;
$threshold = isset( $assoc_args[‘threshold’] ) ? (int) $assoc_args[‘threshold’] : 20;

// 対象テーブル: 断片化が起きやすいwp_postsとwp_postmetaをターゲットに
$tables = [ $wpdb->posts, $wpdb->postmeta ];

foreach ( $tables as $table ) {
// Data_free: 断片化領域, Data_length: データサイズ
$status = $wpdb->get_row( “SHOW TABLE STATUS LIKE ‘$table'” );
$fragmentation = ( $status->Data_free / $status->Data_length ) 100;

if ( $fragmentation > $threshold ) {
WP_CLI::log( “最適化中: $table (断片化率: ” . round( $fragmentation, 2 ) . “%)” );

// 実行開始。InnoDBはオンラインDDLで実行されるため、読み書きは維持される
$wpdb->query( “OPTIMIZE TABLE $table” );

WP_CLI::success( “$table の最適化が完了しました。” );
} else {
WP_CLI::log( “$table は最適化の必要なし。” );
}
}
}
}

WP_CLI::add_command( ‘db-optimize’, ‘DB_Optimize_Command’ );

—

3. パフォーマンス最適化の注意点と教訓

この設計パターンを採用する上で、以下の「コントリビューターの視点」を必ず忘れないでほしい。

1. ディスクI/Oのスパイク: `OPTIMIZE TABLE` は内部で一時ファイルを作成する。テーブルサイズが数GBを超える場合、一時領域として同等以上のディスク空き容量が必要だ。これが不足するとDBのクラッシュに繋がる。
2. レプリケーションラグ: 書き込み負荷が集中するため、Read Replicaが存在する場合、レプリケーションラグが発生する可能性がある。実行時は、トラフィックの少ない時間帯を狙うのが鉄則だ。
3. InnoDB Buffer Poolの汚染: 再構築処理により、キャッシュされていたインデックスデータが一度破棄される。実行直後は一時的にパフォーマンスが低下するため、`innodb_buffer_pool_instances` の適切な設定が前提となる。

—

結論

WordPressを「ただのCMS」として使うか、あるいは「大規模なデータセットを扱う基盤」として掌握するか。その分かれ道は、こうしたデータベースの物理構造への理解にある。

断片化を放置することは、エンジンに砂を混ぜるようなものだ。定期的な計測と、今回提示したような制御された最適化プロセスをCI/CDや定期メンテナンスに組み込むこと。それが、真に堅牢なWordPressインフラを構築するエンジニアの矜持である。

次にコードを書くとき、`$wpdb->get_results()` の裏側で何が起きているか、物理的なページの状態を想像してみてほしい。それが「中級者」を脱し、「アーキテクト」へと至る唯一の道だ。