【入門編】WordPressデータベースの断片化（Fragmentation）の検知と最適化のタイミング – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressの深淵へ：データベースの「断片化」を制する者がパフォーマンスを制す

こんにちは。WordPressのソースコードの海を泳ぎ続けていると、多くの開発者が「なぜかサイトが重い」という壁にぶつかる場面に出会います。キャッシュプラグインを入れたり、画像を圧縮したりしても改善しない。その原因、実は「データベースの断片化」にあるかもしれません。

今日は、WordPressの心臓部であるデータベース（MySQL/InnoDB）の物理的な構造と、パフォーマンスを最大化するための「OPTIMIZE TABLE」の真実について、エンジニアの視点から紐解いていきましょう。

—

1. データベースの断片化とは何か？

WordPressのデータは、主に `wp_posts` や `wp_postmeta` といったテーブルに格納されていますよね。これらはMySQLの「InnoDB」というストレージエンジンで管理されています。

皆さんが記事を更新したり、削除したりするたびに、データベース内では小さな「空き領域」が生まれます。これをフラグメンテーション（断片化）と呼びます。

図解的イメージ

正常な状態: 本棚に本がギッシリ詰まっている（読み込みが速い）。
断片化した状態: 本を抜き取った隙間が点在している。新しい本を入れるには隙間を探さなければならず、本棚を整理する時間（I/O負荷）がかかる。

クエリが実行されるたび、MySQLはこの「隙間」を縫ってデータを読み書きします。断片化が進むと、ディスクの読み込み回数が増え、SQLの実行速度が目に見えて低下するのです。

—

2. 断片化を検知するクエリ

まずは、今のデータベースがどれくらい疲弊しているかを確認しましょう。以下のSQLをphpMyAdminやMySQLクライアントで実行してみてください。

SELECT
table_name AS ‘テーブル名’,
data_free / 1024 / 1024 AS ‘断片化容量(MB)’
FROM
information_schema.tables
WHERE
table_schema = ‘あなたのデータベース名’;

この「断片化容量」が数百MBを超えてきたら、メンテナンスのサインです。

—

3. 「OPTIMIZE TABLE」の是非：エンジニアの心得

ここでよくある質問が、「`OPTIMIZE TABLE` を毎日自動実行してもいいですか？」というもの。

結論から言うと、「頻繁な実行はむしろ悪」です。

InnoDBにおいて `OPTIMIZE TABLE` は、テーブルのコピーを作成して再構築する重い操作です。実行中はテーブルがロックされる（場合がある）ため、アクセス数の多い時間帯に行うとサイトがダウンするリスクがあります。

正しい運用戦略

1. 高頻度で実行しない: 週1回、あるいは月1回で十分です。
2. オフピークを狙う: トラフィックが最も少ない深夜帯に実行します。
3. WP-Cronを活用する: 以下のコード例のように、カスタムフックを作成して管理するのがプロのやり方です。

—

4. 安全なメンテナンスコード例

WordPressのプラグインやテーマの `functions.php` で、直接SQLを叩いて最適化するコード例です。

データベースの断片化を解消するメンテナンス関数

/
function my_custom_db_optimize() {
global $wpdb;

// 最適化対象のテーブルを指定
$tables = array($wpdb->posts, $wpdb->postmeta, $wpdb->comments);

foreach ($tables as $table) {
// SQL実行（OPTIMIZE TABLE）
$wpdb->query(“OPTIMIZE TABLE $table”);
}
}

// 毎週日曜日の深夜2時に実行するスケジュール（WP-Cron）
if (!wp_next_scheduled(‘my_db_optimize_event’)) {
wp_schedule_event(strtotime(‘Sunday 02:00:00’), ‘weekly’, ‘my_db_optimize_event’);
}

add_action(‘my_db_optimize_event’, ‘my_custom_db_optimize’);

—

5. 初学者が陥りやすい罠と注意点

「全テーブルを最適化すればいい」という勘違い:

`wp_options` のような小さいテーブルを頻繁に最適化しても効果は薄く、リソースの無駄です。断片化の大きい `wp_postmeta` など、肥大化しやすいテーブルに絞るのが賢明です。

バックアップを忘れる:

DB操作は常にリスクを伴います。最適化を実行する前に、必ずDB全体のバックアップを取る習慣をつけてください。

「速くならない！」と焦る:

断片化はあくまで「物理的整理」です。もしクエリそのものが非効率（例：`meta_query` の乱用など）であれば、最適化しても速度は劇的には変わりません。その場合は、インデックス設計やクエリの見直しが先です。

—

最後に：WordPressをマスターするということ

データベースの内部構造を知ることは、WordPressというシステムの「体調管理」ができるようになることです。

「なぜこのクエリは遅いのか？」「なぜこのテーブルは大きくなるのか？」という問いを常に持ち続けること。それができれば、あなたは単なる「WordPress利用者」から、一歩進んだ「WordPressエンジニア」になれています。

ここをクリアしたあなたは、もうWordPressのパフォーマンスチューニングの入り口に立っています。自信を持って、次の最適化に挑戦してみてくださいね！