数据库中 catalog_product_price_cl、catalogsearch_fulltext_cl 等表持续膨胀，说明变更事件写入速度超过 MView 消费，或订阅状态已经停滞。直接 truncate 会让索引跳过尚未处理的实体。

先固定复现条件和影响范围

记录每张 *_cl 表的行数、最小与最大 version_id、对应 mview_state 的 version_id 和索引状态，间隔十分钟再次采样，判断生产与消费速度。

SELECT view_id,mode,status,version_id,updated FROM mview_state ORDER BY view_id;
SELECT COUNT(*) cnt,MIN(version_id),MAX(version_id) FROM catalog_product_price_cl;
SELECT COUNT(*) cnt,MIN(version_id),MAX(version_id) FROM catalogsearch_fulltext_cl;
php bin/magento indexer:show-mode
php bin/magento indexer:status
php bin/magento cron:run --group index -vvv

根据证据分支定位

最大 version_id 增长而 state 不动，查 index Cron 与索引错误；state 前进但旧行不清理，检查清理过程与长事务；表没有新行但业务有变更，核对触发器是否存在。Realtime 与 Schedule 模式混用时要确认真实预期。

修复时保留回滚路径

先修复失败索引器或 Cron，观察 state 恢复推进，再让系统正常清理已消费范围。确需人工归档时，只处理严格小于已确认消费 version_id 的记录，并先备份；不能把 state 强行跳到最大值。

上线验收

修改一个商品价格和分类关系，changelog 增加后应在预期周期被消费，前台索引同步。连续观察高峰期，表行数应在可控区间波动而不是单向增长。

生产环境操作前的检查

处理“Magento 2 MView changelog 表持续增长”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；任何写操作、目录清理或配置切换都应确认影响范围、保留备份并准备回滚。多节点环境要核对各节点代码版本、app/etc/env.php 配置摘要与流量分布。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费或订单的改动，先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。准备一个正常对象与一个异常对象对照；若旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层需要保存的证据通过标准
入口层 URL、状态码、请求 ID、节点 路由和协议一致
应用层 异常堆栈、模块、作用域 无新异常且可重复
数据层 主键、时间、关联行数 关系完整且无重复副作用
业务层 正常、失败、重试路径 最终结果一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器和目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。