后台或命令行显示某个索引器长期处于 Processing。直接运行 indexer:reset 有两种风险：真正的进程仍在写索引时被第二个任务并发启动；或者你抹掉了状态，却没有找到导致进程退出的根因。
先记录状态，不执行任何修改
bin/magento indexer:status
bin/magento indexer:show-mode
bin/magento indexer:info
记下 indexer ID、mode、状态和 backlog 数量。若只有一个 indexer 异常，围绕它查；全部异常则优先查 Cron、数据库或部署。
进程还在吗？
ps -eo pid,lstart,etime,cmd | grep -E '[m]agento (indexer:reindex|cron:run)'
pgrep -af 'bin/magento.*(indexer:reindex|cron:run)'
找到 PID 后，不要马上 kill。先确认工作目录、启动时间和打开文件：
readlink -f /proc/PID/cwd
ls -l /proc/PID/fd | head
cat /proc/PID/status | egrep 'State|VmRSS|Threads'进程 CPU/I/O 在变化，且数据库查询推进，可能只是大索引；进程不存在，才更像状态残留。
进程存在但不推进：到 MySQL 找它在等什么
mysql -e 'SHOW FULL PROCESSLIST'
mysql -e 'SHOW ENGINE INNODB STATUSG'
关注长时间 Sending data、Creating sort index、Waiting for table metadata lock 或行锁。metadata lock 常来自未提交的后台会话或部署 DDL；行锁则要找持有事务。确认业务影响后再终止阻塞者，不能按运行时间盲杀。
状态残留的数据库证据
SELECT indexer_id, status, updated, hash_config
FROM indexer_state
ORDER BY updated;
SELECT view_id, mode, status, version_id, updated
FROM mview_state
ORDER BY updated;不同版本字段略有差异。updated 很旧、没有对应 OS/DB 进程、日志显示进程已异常退出，才满足“状态残留”的基本条件。
Update by Schedule 还要看 changelog 是否持续增长
先从 mview 配置确认订阅表，再查看对应 *_cl 表的最大 version_id 和行数。示例：
SELECT COUNT(*) AS rows_waiting, MAX(version_id) AS newest
FROM catalog_product_price_cl;
backlog 快速增长时，即使 reset 成功，全量/增量任务也可能追不上写入速度。需要处理长事务、批量导入频率和 Cron 能力。
满足条件后再 reset 指定索引器
bin/magento indexer:reset catalog_product_price
bin/magento indexer:reindex catalog_product_price
bin/magento indexer:status catalog_product_price
不要无差别 reset 全部索引器。生产全量 reindex 会增加 CPU、I/O 和锁压力，应在容量允许的窗口执行，并观察日志：
tail -f var/log/cron.log var/log/system.log var/log/exception.log
真正完成的标准
状态回到 Ready 只是第一步。再修改一个测试商品价格，确认 changelog 出现新版本、Cron 消费它、索引表更新且前台价格变化。只有“增量更新再次自动工作”，才能说明问题解决；手工全量成功不代表调度链路已经恢复。
