【テクニカル・上級編】WordPressデータベースの断片化（Fragmentation）がクエリ実行計画に与える悪影響とオンライン最適化 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

序：巨大化する `wp_postmeta` の呪縛と InnoDB の物理限界

WordPressのパフォーマンスチューニングにおいて、しばしば「オブジェクトキャッシュの導入」や「クエリの最適化（`no_found_rows = true` の徹底など）」が叫ばれる。しかし、数百万レコードを超えた `wp_posts` および `wp_postmeta` テーブルを抱えるエンタープライズ環境において、どれほど精緻なアプリケーション層のキャッシュを構築しようとも、基盤であるMySQL（InnoDB）のストレージエンジン層で物理的な断片化（Fragmentation）が進行していれば、システムはいずれ致死的なレイテンシの壁に突き当たる。

特に `wp_postmeta` は、EAV（Entity-Attribute-Value）アンチパターンを地で行く設計であり、メタデータの追加・更新・削除が頻発する。これにより、InnoDBのB+樹木（B-Tree）インデックスおよびデータ領域には、深刻な外部断片化（External Fragmentation）とページ内の空き領域（Data Waste）が蓄積されていく。

本稿では、InnoDBのストレージレイアウトとクエリ実行計画（Execution Plan）の深層に踏み込み、断片化がオプティマイザをいかにして誤導するか、そして無停止（オンライン）でこのエントロピーを逆転させるための極限のメンテナンス戦略を解き明かす。

—

1. InnoDBストレージエンジンにおける断片化のメカニズム

ページ（Page）とエクステント（Extent）の物理構造

InnoDBのデフォルトのページサイズは 16KB である。レコードの挿入（`INSERT`）および可変長データ（`longtext` の `meta_value` など）の更新によって、データはこれらのページ単位で分割（Page Split）と結合（Page Merge）を繰り返す。

`wp_postmeta` において、メタキーの更新やシリアライズされた巨大なJSONデータの再書き込みが発生すると、レコードが既存のページに収まらなくなり、InnoDBはページを物理的に2つに分割する。この結果、ページの充填率（Fill Factor）が低下し、ディスク上の論理的な連続性が失われる。

クエリ実行計画（EXPLAIN）への悪影響

断片化が進行したテーブルに対して `WP_Query` が発行されると、MySQLのオプティマイザはコストベース（Cost-based）で実行計画を立案する。

1. ランダムI/Oの増大: 連続しているべきデータが複数のエクステント、ひいてはディスクの離散したセクタに散らばるため、OSおよびストレージサブシステムレベルでシーケンシャルI/OがランダムI/Oへと変質する。
2. バッファプール（Buffer Pool）の汚染: 実際の有効データ量に対して、断片化による「無駄な空き領域」を含んだページまでがメモリ上にロードされるため、InnoDB Buffer Poolのヒット率が劇的に低下する。
3. フルテーブルスキャン（`ALL`）または不適切なインデックススキップ: オプティマイザが「インデックスレンジスキャンよりも、断片化したクラスタ化インデックスの全件走査の方がコストが低い」と誤認し、最悪の実行計画を選択するケースが生じる。

—

2. 断片化の定量検知：INFORMATION_SCHEMAの深層解析

感覚的な「サイトが重い」という診断を排し、数学的・物理的な根拠に基づいて断片化を検知するためのSQLクエリを提示する。

SELECT
table_name AS `Table`,
engine AS `Engine`,
table_rows AS `Rows`,
ROUND(data_length / 1024 / 1024, 2) AS `Data Size (MB)`,
ROUND(index_length / 1024 / 1024, 2) AS `Index Size (MB)`,
ROUND(data_free / 1024 / 1024, 2) AS `Data Free (MB)`,
IF(data_length = 0, 0, ROUND(data_free / (data_length + index_length + data_free) 100, 2)) AS `Fragmentation %`
FROM
information_schema.TABLES
WHERE
table_schema = DATABASE()
AND engine = ‘InnoDB’
ORDER BY
`Data Free (MB)` DESC;

評価指標の読み方

`data_free`: 削除されたレコードや更新によって再利用可能だが、まだ割り当てられたままのバイト数。これが `data_length` の20%を超える場合、あるいは絶対値が数GBに達している場合は、即座に最適化の検討が必要である。

—

3. オンラインでのテーブル再構築（`ALTER TABLE … ALGORITHM=INPLACE`）

伝統的な `OPTIMIZE TABLE` コマンドは、MySQLのバージョンや設定によってはテーブル全体を排他ロック（`LOCK=EXCLUSIVE`）し、書き込みを完全にブロックするため、高トラフィックな本番WordPress環境では実行不可能だった。

しかし、現代のInnoDB（MySQL 5.6以降 / MariaDB 10.0以降）では、`ALGORITHM=INPLACE` および `LOCK=NONE` を用いることで、テーブルへの書き込み（`INSERT`, `UPDATE`, `DELETE`）を許容したまま、バックグラウンドでクラスタ化インデックスの再構築とデフラグメンテーションを実行できる。

極限最適化のためのSQL実行

— wp_postmeta のオンライン再構築
ALTER TABLE wp_postmeta
ENGINE = InnoDB,
ALGORITHM = INPLACE,
LOCK = NONE;

— wp_posts のオンライン再構築
ALTER TABLE wp_posts
ENGINE = InnoDB,
ALGORITHM = INPLACE,
LOCK = NONE;

> アーキテクトの警告: `ALGORITHM=INPLACE` であっても、一時的なログファイル（`innodb_sort_buffer_size` に依存）がディスク上に生成される。十分なストレージの空き容量（対象テーブルのサイズの最低1.5倍〜2倍）を確保した上で実行すること。

—

4. WordPressコアと連動した自動メンテナンス・アーキテクチャ

データベースの物理構造の劣化は、人間が手動で監視・修正するものではない。WordPressのWP-Cron、あるいはOSのCronデーモンと連携し、システム自身が自律的に最適化を判断・実行するパイプラインを構築する。

以下は、WordPressの内部APIをバイパスし、直接データベースドライバ（`$wpdb`）を叩いて安全にメタテーブルの最適化ステータスをチェック・ログ出力、あるいはメンテナンスモードの制御を行うための高度なPHPコードスニペットである。

Plugin Name: Core DB Fragmentation Guard

Description: Monitors InnoDB fragmentation and executes safe online maintenance for WordPress core tables.

Version: 1.0.0

Author: Chief Systems Architect

if ( ! defined( ‘ABSPATH’ ) ) {
exit;
}

class WP_Core_DB_Optimizer {

private const FRAGMENTATION_THRESHOLD_PERCENT = 15.0;
private const COOLDOWN_TRANSIENT = ‘wp_db_opt_cooldown’;

public static function init(): void {
// 日次バッチとしてWP-Cronに登録
if ( ! wp_next_scheduled( ‘wp_core_db_fragmentation_check_event’ ) ) {
wp_schedule_event( time(), ‘daily’, ‘wp_core_db_fragmentation_check_event’ );
}

add_action( ‘wp_core_db_fragmentation_check_event’, [ __CLASS__, ‘evaluate_and_optimize’ ] );
}

断片化率を評価し、閾値を超えている場合に安全な最適化を実行する

/
public static function evaluate_and_optimize(): void {
global $wpdb;

// クールダウン期間のチェック（頻繁な実行を防ぐ: 最低7日間隔）
if ( get_transient( self::COOLDOWN_TRANSIENT ) ) {
return;
}

$target_tables = [
$wpdb->posts,
$wpdb->postmeta,
$wpdb->comments,
$wpdb->commentmeta
];

foreach ( $target_tables as $table ) {
$frag_data = $wpdb->get_row( $wpdb->prepare(
“SELECT
data_length,
data_free,
IF(data_length = 0, 0, (data_free / (data_length + data_free)) 100) AS frag_pct
FROM information_schema.TABLES
WHERE table_schema = %s AND table_name = %s”,
DB_NAME,
$table
) );

if ( $frag_data && floatval( $frag_data->frag_pct ) >= self::FRAGMENTATION_THRESHOLD_PERCENT ) {
self::execute_online_rebuild( $table, floatval( $frag_data->frag_pct ) );
}
}

// クールダウンを7日間に設定
set_transient( self::COOLDOWN_TRANSIENT, true, 7 DAY_IN_SECONDS );
}

INPLACEアルゴリズムを用いた非ブロッキング再構築の実行

/
private static function execute_online_rebuild( string $table_name, float $frag_pct ): void {
global $wpdb;

// 実行ログの記録
error_log( sprintf(
‘[DB Optimizer] Table %s fragmentation reached %.2f%%. Initiating INPLACE rebuild.’,
$table_name,
$frag_pct
) );

// タイムアウトを一時的に拡張（大規模テーブル対策）
@ini_set( ‘max_execution_time’, ‘600’ );

// 構文の安全性を担保するためテーブル名をバッククォートでエスケープ
$safe_table = ‘`’ . esc_sql( str_replace( ‘`’, ”, $table_name ) ) . ‘`’;

// オンライン最適化クエリの実行
// 注意: MySQL 5.6+ / MariaDB 10.0+ 必須
$sql = “ALTER TABLE {$safe_table} ENGINE = InnoDB, ALGORITHM = INPLACE, LOCK = NONE;”;

$result = $wpdb->query( $sql );

if ( false === $result ) {
error_log( sprintf(
‘[DB Optimizer] CRITICAL: Failed to rebuild table %s. Error: %s’,
$table_name,
$wpdb->last_error
) );
} else {
error_log( sprintf(
‘[DB Optimizer] SUCCESS: Table %s successfully rebuilt in place.’,
$table_name
) );
}
}
}

WP_Core_DB_Optimizer::init();

—

5. 高度なエンジニアリングのための設計指針とまとめ

データベースの最適化は、単に「クエリを速くする」という表面的なアプローチに留まらない。ハードウェアのキャッシュライン、OSの仮想メモリ、そしてストレージエンジンのB+樹木の物理構造に至るまで、データのライフサイクル全体を俯瞰して初めて真のパフォーマンスが達成される。

定期的な死活監視: `information_schema.TABLES` を用いた断片化メトリクスの監視をオブザーバビリティ（可観測性）スタックに組み込むこと。
適切なメンテナンスウィンドウ: `ALGORITHM=INPLACE` は運用中の書き込みをブロックしないが、CPUとディスクI/Oのリソースを一時的に消費するため、トラフィックの谷間（深夜帯など）に実行されるようスケジューリングすることが望ましい。
EAVの限界への備え: `wp_postmeta` 自体の肥大化が限界値を超えた場合、カスタムテーブル（Custom Tables）への移行、あるいはTiDBなどの分散SQLデータベース層への移行をも視野に入れたアーキテクチャ設計が、シニアエンジニアに求められる究極の備えである。