2meet-data-optimizer.php

@@ -3,7 +3,7 @@
  * Plugin Name:       2meet Data Optimizer
  * Plugin URI:        https://2meet.io/2meet-data-optimizer
  * Description:       通用 WordPress 反 EAV 引擎：將 postmeta / usermeta / termmeta / commentmeta 自動分流至四象限扁平表（Hot / Warm / Cold / Archive），大幅提升搜尋與篩選效能。從 wp-data-optimizer v2.16.0 提煉的純核心，整合層交給 11 個 AddOn。
- * Version:           1.3.0
+ * Version:           1.4.0
  * Requires at least: 6.0
  * Tested up to:      6.9.4
  * Requires PHP:      8.1
@@ -26,7 +26,7 @@ if ( ! defined( 'ABSPATH' ) ) {
 }
 
 // ── Constants ──────────────────────────────────────────────────────────────
-define( 'TMDO_VERSION', '1.3.0' );
+define( 'TMDO_VERSION', '1.4.0' );
 define( 'TMDO_DB_VERSION', '2.1.0' );
 define( 'TMDO_PATH', plugin_dir_path( __FILE__ ) );
 define( 'TMDO_URL', plugin_dir_url( __FILE__ ) );

CHANGELOG.md

@@ -7,6 +7,48 @@ Versioning follows [Semantic Versioning](https://semver.org/).
 
 ---
 
+## [1.4.0] — 2026-09-28 — 百萬級 listing 的路由排序與日期查詢（hardening 2.4）
+
+**性質**：效能 + 修正。無 schema 變更；post status/date 副本的索引改為三欄（`wp tmdo post-status-sync` 就地替換）。
+搭配 HivePress AddOn 0.5.0。來源：dev36 第 3 階壓測（130 萬 listing、121 萬 product、6.2 萬 vendor）。
+
+### Changed
+
+- **flat-first 排序讀 flat 的 post_id 作 tie-break**：`posts.ID` 的 tie-break（ours 與外掛追加的）
+  改讀相等的 `flat.post_id`，方向與排序一致且只出現一次；group 宣告的索引可以 adapter 的
+  entity id 欄結尾，`(欄, post_id)` 索引可直接依序讀取、不需 filesort（主查詢 850 ms → 2 ms）。
+  同值的順序改為依 ID 與排序同方向（原生為 ID DESC）；集合、總數不變，翻頁穩定。（PR-118）
+- **沒有 value 的 meta 條件以 EXISTS 路由**：clause 沒有 `value` 時（HivePress 的精選 listing
+  查詢）視同 EXISTS；只帶 `meta_key`、沒有 `meta_value` 也不以 meta_value 排序的查詢亦同；
+  沒有被 orderby 引用的排序形狀 group 直接移除。HivePress 每個搜尋頁都會跑的精選 listing
+  查詢（`orderby rand`）改走扁平表：2.26 s → 0.2 s。（PR-122）
+- **status/date copy route 在 LIMIT 停下**：只有扁平表一個 JOIN 時去掉 WordPress 的
+  `GROUP BY posts.ID`，`posts.ID` tie-break 改讀 `flat.post_id`（各自保留方向、重複合併）；副本索引改為
+  `idx_post_status_date_id (post_status, post_date, post_id)`，取代兩欄的 `idx_post_status_date`。
+  dev36 價格區間（130 萬中 23.5 萬筆符合）主查詢 1.7 s → 3 ms，頁面 2.7 s → 0.34 s。（PR-128）
+
+### Fixed
+
+- 遷移引擎（backfill、`drift-check --fix`）以 REPLACE 重建 post 列時保留 `post_status` /
+  `post_date` 副本；原本重建後為 NULL，一筆 NULL 就讓整個 group 關閉 copy route。（PR-127）
+- 遷移引擎重建 post 列後遞增路由計數版本（每次呼叫／每批一次，dry run 不遞增），
+  修正後的 found rows 不再沿用舊的快取計數。（PR-129）
+
+### Dev
+
+- live 測試工具（`mut.php`、`qbench.php`）不再清空物件快取（Redis Object Cache 以伺服器端腳本
+  掃描，會卡住共用 Redis 5–20 s）。（PR-123）
+
+### 升級後
+
+- 已啟用 post status/date 副本的站（`tmdo_post_status_columns` 有 `ready` 的 group）執行一次
+  `wp tmdo post-status-sync`：替換索引並重新同步副本（dev36 130 萬列約 75 s）。未執行前
+  copy route 照常運作，只是維持 1.3.0 的速度。
+- 效能數字（dev36 前台，routed）：價格區間 0.34 s、價格排序 0.37 s、時薪排序 0.35 s、
+  評分排序 0.51 s、關鍵字 + 價格 0.59 s（原生 6–43 s）。
+
+---
+
 ## [1.3.0] — 2026-09-27 — 大表索引、路由計數與稽核修正（hardening 2.3）
 
 **性質**：效能 + 稽核修正。無 schema 變更（宣告的複合索引以 ALTER ADD INDEX 就地加上）。

readme.txt

@@ -4,7 +4,7 @@ Tags: performance, database, postmeta, optimization, hivepress
 Requires at least: 6.0
 Tested up to: 6.9
 Requires PHP: 8.1
-Stable tag: 1.3.0
+Stable tag: 1.4.0
 License: GPLv2 or later
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
 
@@ -107,6 +107,13 @@ The Classifier tab analyzes your existing `wp_postmeta` data (access frequency,
 
 == Changelog ==
 
+= 1.4.0 =
+* Flat-first sorts read the ID tie-break from the flat post_id, so a declared (column, post_id) index returns rows in order; ties now follow the sort direction
+* Meta clauses without a value route as EXISTS; HivePress's featured-listing lookup on every search page uses the flat table
+* Date-ordered routed searches drop the redundant GROUP BY and use a (post_status, post_date, post_id) index (run `wp tmdo post-status-sync` once to replace the index)
+* Rows rebuilt by the migration engine keep their status/date copies and invalidate cached routed counts
+* Live test tools no longer flush the object cache
+
 = 1.3.0 =
 * Declared flat-table indexes are added only from WP-CLI or WP-Cron, one process at a time (MySQL GET_LOCK); web requests schedule `tmdo_ensure_group_indexes`, and doctor lists indexes not added yet
 * Routed searches with post__not_in count from a cached base count minus the excluded posts; the cache key ignores wpdb's per-request placeholder escape and follows post saves and managed-key writes only, not every post meta write (HivePress keyword + price search no longer slower than native)