やあ。WordPressの深淵へようこそ。
多くの開発者がWordPressを「ただのブログツール」だと思っているけれど、その中身は数千万件のレコードをさばくポテンシャルを秘めた巨大なデータプラットフォームだ。しかし、この「心臓部」であるMySQL/InnoDBの挙動を理解せずに運用すると、ある日突然、クエリのレスポンスが極端に遅くなるという「死の淵」に立たされることになる。
今日は、WordPressのデータベース、特に`wp_posts`や`wp_postmeta`がなぜ「太る」のか、そしてサービスを止めずにどうやってその健康を維持するのか、核心に迫っていこう。
—
1. なぜWordPressのDBは「断片化」するのか？
InnoDBというエンジンは、データを「ページ」という単位で管理している。ここで重要なのは、「削除や更新は、物理的にデータを消すわけではない」という事実だ。
- レコードの削除: 削除した領域は「空きスペース」としてマークされるだけで、ファイルサイズは縮まない。
- レコードの更新: 文字列が長くなると、現在のページに入りきらなくなり、新しいページへ移動する（ページ分割）。元の場所にはスカスカの穴が開く。
これが「断片化（Fragmentation）」だ。無数の穴が開いたテーブルをスキャンするとき、MySQLは無駄な空きスペースまでメモリに読み込む。これがパフォーマンス低下の正体さ。
イメージ図：断片化されたストレージ
[データA][空き][データB][空き][空き][データC]
↑ 読み込み効率が低下し、I/O負荷が激増する
—
2. オンライン最適化のベストプラクティス
多くの初心者がやりがちな間違いは、`OPTIMIZE TABLE`コマンドを頻繁に叩くことだ。これはテーブル全体を再構築するため、大規模テーブルではテーブル全体がロック（排他）され、サイトが長時間ダウンするリスクがある。
本物のエンジニアなら、以下の戦略をとるべきだ。
戦略A：`pt-online-schema-change` を使う（推奨）
Percona Toolkitに含まれるこのツールは、新しいテーブルを作成し、トリガーを使ってデータを同期させながら、最終的にテーブルを入れ替える。サイトを止めないための業界標準さ。
戦略B：WP-CLIを活用した定期メンテナンス
もしあなたが小〜中規模の環境なら、WP-CLIを使って「夜間の負荷が低い時間」にピンポイントで最適化するのが賢いやり方だ。
wp-cliを使ってデータベースを最適化するコマンド
–dry-runをつけると実際に実行せずチェックできる
wp db optimize –dry-run
実際に実行する場合
wp db optimize
—
3. 実践：断片化を監視するカスタムコマンド
どのテーブルがどれくらい断片化しているか、WordPressの管理画面から見えないと不安だよね？ 以下のコードを`functions.php`や自作プラグインに仕込んでおけば、今のデータベースの健康状態が一目でわかるようになる。
/
- データベースの断片化状況を確認する関数
- @return void
/
function check_db_fragmentation() {
global $wpdb;
// データ長とデータフリー（断片化）を取得するクエリ
$results = $wpdb->get_results(”
SELECT
table_name AS ‘テーブル名’,
round(data_length / 1024 / 1024, 2) AS ‘データサイズ(MB)’,
round(data_free / 1024 / 1024, 2) AS ‘断片化サイズ(MB)’
FROM information_schema.tables
WHERE table_schema = DATABASE()
“);
echo ‘
';
print_r($results);
echo '
‘;
}
// 管理画面のダッシュボードウィジェット等で呼び出すと便利だね
—
4. 陥りやすい罠とアドバイス
「`wp_postmeta`を巨大化させない」という鉄則
`wp_postmeta`はWordPressで最も断片化しやすいテーブルだ。カスタムフィールドを多用しすぎると、ここが肥大化し、インデックスの検索効率がガタ落ちする。
- 解決策: 不要なメタデータは定期的に削除する（`wp_delete_post`で記事を消しても、メタデータが残る場合があるから注意してね）。
「revision」という名の罠
WordPressには標準でリビジョン機能がある。記事を編集するたびに`wp_posts`にレコードが増え、それに紐づく`wp_postmeta`も増える。
`wp-config.php`に以下を書いて、リビジョンの数を制限しよう。
// リビジョンを最大3つまでに制限して無駄なレコード増加を防ぐ
define( ‘WP_POST_REVISIONS’, 3 );
—
最後に
データベースの最適化は、車のエンジンオイル交換と同じだ。放置すれば確実にパフォーマンスは落ちるし、いざという時に取り返しのつかない重さになって返ってくる。
「動いているからいいや」ではなく、裏側のデータ構造を想像しながらコードを書く。これができるだけで、君は他のWordPressエンジニアより一歩も二歩も抜きん出ることができるはずだ。
ここをクリアした君なら、次はインデックス設計やクエリキャッシュの最適化へ進める準備ができている。WordPressという広大な宇宙を、もっと深く探索してみようじゃないか。
またいつでも相談してくれ。応援しているよ。