reindex?

把 Magento 想成「圖書館」：

• EAV 就是把一本書拆成很多小貼紙（標題、作者、顏色、尺寸…分散在不同抽屜）。彈性超大，但要找起來很慢。
• Reindex 就是把零散的貼紙，預先抄到好查的索引卡（flat / 索引資料表）。
• 前台（購物頁、分類頁、搜尋）不直接看貼紙，而是看索引卡，所以快。

關鍵一句：你改了資料（貼紙）不代表索引卡會立刻更新。
沒有 Reindex，前台常常就「沒變」或「不一致」。

為什麼 Magento 一定要 Reindex？

因為 Magento 把商品、分類、價格、庫存…等資訊用 EAV 拆得很細，超彈性但查詢慢。
Reindex 會把這些分散資料「算好、整理好」，放進更好查詢的表，前台就能飛快讀到。

你要認識的 Indexers（常見清單）

執行 bin/magento indexer:info 會看到一串，常見且影響大的有：

• catalog_product_price：單價、特價、階梯/群組價、規則價
• cataloginventory_stock：庫存與可售狀態（in stock / out of stock）
• catalog_category_product：商品與分類的對應
• catalogsearch_fulltext：搜尋索引（ES / OpenSearch / MySQL 視版本設定）
• catalog_product_attribute、catalog_product_flat（若啟用）、catalogrule_rule/catalogrule_product（目錄價規則）

這些就是「哪個前台功能會快、會準」的關鍵來源。

Reindex 的兩種模式（一定要會）

每個 indexer 都能切換模式：

1. Update on Save（即時）

• 你在後台改一個商品，該商品相關索引立刻重建。
• 優點：前台幾乎即時。
• 缺點：大量更新時會「每筆都重建」，很卡。

2. Update by Schedule（排程）

• 改資料時只記錄「變動清單（changelog）」；
• 由 cron 定時把變動批次套入索引表。
• 優點：大量更新穩、效能好。
• 缺點：前台會有一點延遲（取決 cron 頻率）。

切換指令：

# 全部設即時
bin/magento indexer:set-mode realtime

# 全部設排程
bin/magento indexer:set-mode schedule

# 看目前狀態
bin/magento indexer:status
bin/magento indexer:show-mode

一次搞懂「排程式」Reindex 在做什麼

• 你改了商品 → Magento 把「被改到的 ID」丟進 changelog（例如：catalog_product_entity_*_cl 這類 *_cl 表）。
• cron 週期性工作（indexer_update_all_views 等）會把 changelog 的變動套用到目標索引表。
• 成功後把 changelog 的版本往前推，等待下一批。

所以「排程不起來」= 變動永遠卡在 changelog，前台就一直舊資料。

什麼時候需要 Reindex？

• 新增/修改商品：名稱、屬性、可見性、啟用狀態
• 調整價格：特價、目錄價規則、分組/階梯價
• 分類變動：商品搬家、排序、分類啟用/隱藏
• 庫存更新：數量、在庫狀態
• 搜尋引擎內容變動：影響 fulltext 的欄位變更

現場常見三種「怪」

1. 前台資料沒變

• 檢查：bin/magento indexer:status 是否 invalid 或卡 processing。
• 解法：bin/magento indexer:reset → bin/magento indexer:reindex（或等 cron 跑）。

2. 大量更新時後台慢、儲存卡很久

• 檢查：當前模式是不是 realtime。
• 解法：大量更新前先切 schedule，讓變動進 changelog，由 cron 批次吃。

3. 搜尋結果不準 / 搜不到

• 檢查：catalogsearch_fulltext 狀態、搜尋引擎服務（ES/OpenSearch）是否正常。
• 解法：bin/magento indexer:reindex catalogsearch_fulltext，並確認搜尋服務健康度。

實用指令（你會一直用到）

# 全部重建
bin/magento indexer:reindex

# 指定某幾個
bin/magento indexer:reindex catalog_product_price cataloginventory_stock

# 重設狀態（把 processing/invalid 變可重建）
bin/magento indexer:reset

# 顯示模式 / 狀態
bin/magento indexer:show-mode
bin/magento indexer:status

跟 Cache 的分工（超容易混）

• Cache（如 FPC、block、config）：把「算好的結果」存起來，下次直接拿。

• Index：把「資料怎麼算」的中間結果整理好，讓前台查得快。

• 症狀判斷：

  • 改了價格、庫存、分類 → 多半是 Index 問題。
  • 前台佈局/文案沒更新或斷斷續續 → 多半是 Cache 問題。

• 很多時候兩個都要處理：先 reindex，再清 cache。

大量變更最佳實務（部署/匯入/腳本）

1. 變更前

   • 將大量受影響的 indexers 切到 schedule。
   • 確認 cron 正常（crontab -l、bin/magento cron:run 手動驗證一次）。

2. 批量更新中

   • 避免每筆都觸發 reindex（所以不要 realtime）。

3. 變更後

   • 手動 bin/magento indexer:reindex（可選）或等待 cron 完成。
   • 視需要清理相關 cache。

4. 回復日常

   • 若你的站點平常要即時更新，可把少數關鍵 indexer 切回 realtime；
   • 但多數中大型站點會長期維持 schedule。

常見坑 & 快速排查

• 狀態一直是 processing

  • 有時是先前中斷、鎖定未釋放；先 indexer:reset 再 reindex。

• cron 沒跑

  • 沒安裝或被移除：bin/magento cron:install / cron:remove
  • 系統層級沒啟動：檢查 crond、systemctl status crond、容器排程策略。

• 排程有在跑但一直沒更新

  • 看資料庫 cron_schedule 是否塞滿失敗；
  • 檢查 var/log/system.log、var/log/exception.log 是否有索引錯誤。

• 搜尋索引成功但前台仍不準

  • 檢查搜尋服務健康（ES/OpenSearch 索引是否綠燈、磁碟空間是否足）。

速查表（貼在 your Notion/README）

• 看到前台資料沒動 → indexer:status、必要時 indexer:reindex
• 大量更新要快 → 切 schedule，確保 cron 正常
• 搜尋不準 → 重建 catalogsearch_fulltext + 檢查搜尋服務
• 卡 processing → indexer:reset → 再 reindex
• 清 Cache ≠ Reindex（兩者不同；必要時兩個都做）

結語

Reindex 不是把資料「清掉重來」，而是把零碎資料整理成好查的結果表。
只要記住三件事：

1. 什麼動作會影響哪個 indexer；
2. 什麼時候該用 realtime、什麼時候用 schedule；
3. cron 一定要健康。

把這三件事做好，前台「怪怪的」的機率就會大幅下降。