后台看到 catalog_product_price 长时间处于 Working，很多人第一反应是 indexer:reset。这个操作本身不一定错，但如果真正的索引进程仍在写临时表，Reset以后马上再启动一个进程，反而可能出现两个任务抢锁、临时表被交叉rename的情况。

第一步：区分“状态没改回来”和“任务还在跑”

bin/magento indexer:status catalog_product_price
ps -ef | grep "indexer:reindex catalog_product_price" | grep -v grep
ps -ef | grep "cron:run" | grep -v grep

还要看MySQL，因为PHP进程可能已经退出，但数据库仍在回滚大事务。以下查询重点看 State、Time 和等待对象。

SHOW FULL PROCESSLIST;
SELECT waiting_pid, waiting_query, blocking_pid, blocking_query
FROM sys.innodb_lock_waits;

如果能看到 catalog_product_index_price、catalog_product_index_price_tmp 或 *_replica 相关SQL仍在执行，就先处理阻塞源。不要直接 kill 写入索引表的进程，除非已经确认它失去控制；大事务被kill后回滚可能比继续执行更久。

再看索引状态表和MView积压

SELECT indexer_id,status,updated FROM indexer_state
WHERE indexer_id='catalog_product_price';

SELECT view_id,version_id,status,updated FROM mview_state
WHERE view_id LIKE '%price%';

如果价格索引使用“按计划更新”，还要比较 changelog 的最大 version_id 与 mview_state.version_id。表名因版本和维度而异，可以先用 SHOW TABLES LIKE '%price%cl%' 找到实际变更日志。积压很大时直接全量reindex不一定是最优方案，先确认Cron和消费者没有持续写入。

确认没有活动进程后再恢复

bin/magento indexer:reset catalog_product_price
bin/magento indexer:reindex catalog_product_price
bin/magento indexer:status catalog_product_price

若每次都卡在同一阶段，打开详细输出并记录最后一条SQL。

bin/magento indexer:reindex catalog_product_price -vvv 2>&1 | tee /tmp/price-index.log

常见根因包括：磁盘临时表空间不足、某个自定义价格插件让SQL无法使用索引、旧临时表权限不对、MySQL元数据锁等待，以及并行Cron重复启动。处理根因后再重建，比定时执行 indexer:reset 靠谱。

验证不能只看“Ready”

  • 随机抽取简单商品、可配置商品和分组客户价格，比较前台最终价
  • 查询 catalog_product_index_price 中对应 entity_id、website_id、customer_group_id 是否齐全
  • 清理全页缓存后用无登录和登录客户各访问一次
  • 观察下一轮Cron后状态是否仍能从Working回到Ready
Reset只修改索引器状态，不会自动解除MySQL锁，也不会修复导致索引失败的代码。把它当作恢复动作，而不是根因修复。