用途：解决 WooCommerce 商店性能问题。资料指出常见瓶颈集中在产品查询未建索引、无限制的 AJAX 购物车/结账调用、缺少持久对象缓存、wp_options 自动加载数据膨胀，以及 wp_woocommerce_sessions 与订单表缺乏清理。
适用时机：中等流量下页面加载慢、AJAX 调用期间 CPU 飙升、MySQL 查询时间为主要瓶颈、wp_options 自动加载体积超过 1–2 MB、会话表行数达百万级，或需引入 Redis/Memcached 降低 MySQL 负载时。
主要能力与用法：
- 先用 Query Monitor 分析，关注每页查询数（超 50 需注意）、重复查询、慢查询（单条超 100ms）和大结果集；安装命令为 wp plugin install query-monitor --activate。生产环境可开启 MySQL 慢查询日志。
- 启用 Redis 持久对象缓存，安装 redis-server 与 redis-cache 插件（wp plugin install redis-cache --activate；wp redis enable），并在 wp-config.php 中配置 WP_REDIS_HOST、PORT、DATABASE、TIMEOUT、READ_TIMEOUT、MAXTTL，并用 WP_REDIS_IGNORED_GROUPS 排除会话等易变数据。
- 为产品与订单 meta 查询补充索引，并按需使用 HPOS 将订单迁出 post meta；可用 wp wc hpos status 查看状态，wp wc hpos migrate --batch-size=500 迁移。
- 通过 Action Scheduler 定时清理过期会话、瞬态与超过 30 天的 WooCommerce 日志，DELETE 使用 LIMIT 分批。
- 优化 wp_options：用 SQL 找出体积最大的自动加载项，改用非自动加载选项或瞬态。
- 示例还包括产品卡片片段缓存与缓存失效、以及用 wc_get_products 避免 N+1 查询。
最佳实践：优先启用持久对象缓存；清理任务安排在低峰期并限制每批行数；生产环境勿开启 WP_DEBUG_LOG 与 SAVEQUERIES；后台订单查询需分页；每周监控 wp_options 自动加载体积。
限制与注意：启用 HPOS 前需审计插件对 get_post_meta 的使用；Redis 命中率低通常说明缓存键失效过频或 TTL 过短；清理可能造成表锁；导入后需主动清理产品缓存。具体支持的 WooCommerce 或 WordPress 版本要求，资料未提供。