后台保存一个商品需要几十秒，问题通常不在商品表本身，而在保存后触发的索引、库存、URL 重写、图片处理或第三方扩展。不要一开始就执行全站缓存清理，它既不能找出慢点，还会增加前台压力。

先确认慢在哪一步

打开浏览器开发者工具的 Network，观察保存请求本身是否很慢。如果请求很快但页面跳转慢，应继续检查后台页面资源；如果保存请求耗时很长，再查看同一时间的 PHP、Web 服务器和 Magento 日志。

tail -f var/log/system.log var/log/exception.log
bin/magento indexer:status
bin/magento indexer:show-mode

检查索引模式

生产环境通常更适合让可调度的索引器使用“按计划更新”。如果多个重量级索引器处于“保存时更新”，每次商品保存都会同步执行相关计算。

bin/magento indexer:set-mode schedule catalog_product_price catalogsearch_fulltext
bin/magento indexer:status
bin/magento cron:run --group=index

修改模式后必须确认 Cron 正常运行，否则只是把“保存很慢”变成“前台数据一直不更新”。

查数据库锁，不要只看慢查询

SHOW FULL PROCESSLIST;
SELECT * FROM performance_schema.data_lock_waits;

第二条查询是否可用取决于 MySQL 版本和权限。重点看保存时是否在等待库存、价格、URL 重写或自定义表的事务。若长期存在锁等待，应找到持锁事务的业务来源，不要直接终止未知生产事务。

排查 Plugin 和 Observer

商品保存会经过 Repository、资源模型和多个事件。第三方扩展如果在保存过程中同步调用外部 API、遍历全部商品或重复保存当前商品，会明显拖慢请求。

bin/magento dev:di:info Magento\Catalog\Api\ProductRepositoryInterface

可在测试环境临时禁用可疑模块做对照，但不要在生产站点随意切换模块。自定义逻辑应记录每个阶段的耗时：

$startedAt = microtime(true);
$this->processor->execute($product);
$this->logger->info('Product post-save processor', [
    'sku' => $product->getSku(),
    'seconds' => round(microtime(true) - $startedAt, 3)
]);

几个容易忽略的原因

  • 商品分配到大量网站或分类，导致关联数据和 URL 重写工作量增大。
  • 可配置商品包含大量子商品，扩展又在保存时逐个加载完整模型。
  • 远程媒体存储、搜索服务或 ERP 接口响应慢。
  • 消费者未运行，导致本应异步的任务回落或积压。
  • PHP-FPM 工作进程不足，后台请求实际在排队。

修复后怎么验证

使用同一个商品连续保存三次，分别记录请求时间、SQL 等待和索引积压。还要再修改一次价格或库存，确认前台能自动更新。只有保存速度和数据一致性同时恢复，才算真正解决。