WooCommerce の注文はshop_orderというカスタム投稿タイプとして wp_posts に保存され、顧客情報や商品内容はすべてwp_postmetaに付随する形で管理されます。
ゲストユーザーの情報もこのメタ情報に保持されるため、 1 件の注文につき多数のメタ行が発生します。
これは、 WordPress 標準の柔軟性を活かした構造である一方、注文が増えるとwp_postmetaが肥大化し、特にメタクエリ（JOIN）による注文検索の遅延が大きな問題になってきます。
数千~数万件と注文が増えるにつれ、構造的なボトルネックになってきます。
従来構造
たとえば、 1 件の注文データ（#1001）を保存する際、次のように保存されます。
- wp_posts
- wp_postmeta
wp_posts
ID post_type post_status post_date post_author
1001 shop_order wc-completed 2025-06-01 12:34:56 0
wp_postmeta
post_id meta_key meta_value
1001 _billing_first_name 太郎
1001 _billing_last_name 山田
1001 _billing_email taro@example.com
1001 _billing_address_1 東京都新宿区 1-2-3
1001 _shipping_method flat_rate
1001 _payment_method cod
1001 _order_total 5980
1001 _line_items シリアライズされた商品配列
1001 _order_currency JPY
このメタデータは抜粋であり、実際には 20～50 行にも分散します。
例えば「顧客名・メール・合計金額」を 1 画面で表示するには、それぞれのmeta_keyを持つ行を探して結合する処理が必要でwp_postmetaの構造的欠点です。
また、meta_valueがシリアライズされていれば、 SQL では直接使えないためさらに遅くなります。
HPOS（High-Performance Order Storage）
この問題を解決するために、 WooCommerce 7.1 以降で導入されたのが、 HPOS（High-Performance Order Storage）です。
HPOS では注文データが以下のような専用テーブルに分離されます。
- wp_wc_orders
- wp_wc_order_addresses
- wp_wc_order_operational_data
それぞれの情報がカラム単位で直接保持されており、必要なデータは 1 行または 1 テーブル JOIN だけで完結します。
検索もWHERE payment_method = 'cod'のように 高速な条件指定が可能です。
wp_wc_orders
id status currency total_amount payment_method date_created_gmt
1001 wc-completed JPY 5980 cod 2025-06-01 03:34:56
wp_wc_order_addresses
order_id address_type first_name last_name email address_1
1001 billing 太郎 山田 taro@example.com 東京都新宿区 1-2-3
wp_wc_order_operational_data
order_id shipping_method created_via ip_address user_agent
1001 flat_rate checkout 192.168.0.1 Mozilla/5.0 (Windows NT 10.0; Win64; x64)
HPOS 導入の効果
| 処理 | 従来構造 | HPOS |
|---|---|---|
| 一覧表示 | meta_key を JOIN（遅い） | 単純 SELECT（速い） |
| 検索 | LIKE 検索、インデックス非効率 | WHERE 検索、高速 |
| ソート | 文字列比較、型変換が必要 | 数値・日付カラムで直接 |
| 絞り込み | meta_key 組み合わせが複雑 | WHERE 句で簡潔 |
| 集計 | meta_key で集計（重い） | SUM 関数で直接集計 |
| ページ分割（件数取得） | JOIN 付き COUNT で遅い | 単純な COUNT(*) で高速 |
HPOS 導入時の互換モードとは？
互換モードを有効にします（高性能注文ストレージ [HPOS] と WordPress 投稿ストレージ間で注文を同期します）。
互換モードとは、高パフォーマンス注文ストレージ（HPOS）を有効にした際、従来の wp_posts / wp_postmeta にも注文データを書き込み・同期する仕組みです。これにより、 HPOS 非対応のプラグインや外部ツールでも、従来通り注文データの取得や更新が可能になります。一見、安全策のように思えますが、注意すべきポイントも存在します。
互換モードの役割・特徴
- 注文データが新旧両方のテーブルに同時保存される
- HPOS 対応の画面や機能は高速化されるが、未対応プラグインは引き続き従来の非効率なメタ情報構造に依存
- そのため、データベース容量は従来より増加する
つまり、互換モードのままでは、 HPOS 本来の高速化や省スペース化といったメリットを十分に享受できません。このため、互換モードはあくまで一時的なつなぎや移行過渡期のための措置と考えるべきです。
原則として、完全な HPOS 運用（真のメリット享受）には、互換モード OFF が絶対条件となります。もし未対応のプラグインが今後も対応見込みがない場合はこのタイミングで代替プラグインの導入や整理をおすすめします。
HPOS 専用運用（互換モード OFF）でのデータ削除について
互換性が一切不要な場合（すべてのプラグイン・テーマが HPOS に対応している場合）は従来の注文データを完全に削除しても問題ありません。
wp_posts：post_type = 'shop_order'の投稿wp_postmeta：注文のpost_idに紐づくメタ情報
以下は、約 6,000 件の注文を持つサイトで HPOS 移行時に実際に測定したデータ量。 40%ほどの削減効果が確認できました。
| ファイル名 | サイズ | 備考 |
|---|---|---|
| noral_strage.sql | 64,239 KB | 削除前のフルデータ |
| hpos_strage（削除後）.sql | 39,905 KB | wp_posts の shop_order 削除後の状態 |
HPOS 導入におけるデメリットは基本的にありません。ただし、未対応のプラグインを使用しているなど、実際の HPOS 導入は「一筋縄ではいかない」ことも。
筆者自身の環境でも想定外のトラブルに遭遇したので、現場での移行ノウハウや注意点は次回まとめます。
この記事が役に立ったら「いいね」！
