カテゴリー
WordPressプラグイン

WooCommerce の高速化-注文構造と HPOS の意義

WooCommerce の注文データは WordPress の投稿テーブルとメタテーブルに保存されてきましたが、注文数が増えると検索や集計で深刻なパフォーマンス問題が発生します。新たに導入された HPOS では、専用テーブルに分離され、検索・集計・一覧表示などが劇的に高速化されます。本記事では、従来方式と HPOS の構造・性能の違いを実例とともに解説します。

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 導入は「一筋縄ではいかない」ことも。
筆者自身の環境でも想定外のトラブルに遭遇したので、現場での移行ノウハウや注意点は次回まとめます。

この記事が役に立ったら「いいね」!

profile image

執筆:R3098

WEB サービス構築・監修が生業です。 WordPress 関連では Aurora Heatmap などプラグイン開発も行っています。悩めるサイト運営者の無料相談受付けます!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトは reCAPTCHA によって保護されており、Google のプライバシーポリシー および 利用規約 に適用されます。

reCaptcha の認証期間が終了しました。ページを再読み込みしてください。