url_rewrite 表记录商品、分类、CMS 和自定义路由。记录很多不一定是故障：多网站、多 store view、分类路径和历史重定向都会增加数量。应先找增长来源，再决定是否处理。

先统计，不要直接清表

SELECT entity_type, store_id, redirect_type, COUNT(*) AS total
FROM url_rewrite
GROUP BY entity_type, store_id, redirect_type
ORDER BY total DESC;

SELECT DATE_FORMAT(created_at, '%Y-%m-%d') AS day, COUNT(*) AS total
FROM url_rewrite
GROUP BY day
ORDER BY day DESC
LIMIT 30;

某些版本的表可能没有 created_at，执行前先使用 DESCRIBE url_rewrite 核对结构。

检查重复模式

SELECT store_id, request_path, COUNT(*) AS total
FROM url_rewrite
GROUP BY store_id, request_path
HAVING COUNT(*) > 1
ORDER BY total DESC;

正常结构通常要求同一 store 下 request_path 唯一。若出现重复，应先确认索引和约束状态，再查第三方导入脚本是否绕过 Repository 直接写表。

为什么会持续增长

  • 商品 URL Key 经常变化，并开启创建永久重定向。
  • 商品分配到大量分类，且配置生成分类路径。
  • 导入任务每次都生成新的 URL Key。
  • 第三方扩展重复创建自定义重写。
  • 多语言 store view 为同一实体生成独立路径。

不要盲目删除 301

历史重定向可能承接搜索引擎和外部链接。批量删除会造成 404 和 SEO 流量损失。应先导出候选记录，确认目标路径仍有效，并与站点日志中的访问情况对照。

修复生成来源

如果增长来自导入程序，确保只有 URL Key 实际变化时才保存商品，并避免循环保存同一实体。自定义 URL 重写应使用稳定的唯一标识和 request_path，写入前检查现有记录。

// 伪代码：只有新旧 URL key 不同时才提交变更
if ($oldUrlKey !== $newUrlKey) {
    $product->setUrlKey($newUrlKey);
    $productRepository->save($product);
}

处理前后的验证

  1. 备份数据库并记录各类重写数量。
  2. 在预发布环境复现清理方案。
  3. 检查主要商品、分类和 CMS URL。
  4. 抽查旧 URL 是否仍正确 301 到新地址。
  5. 运行一轮商品导入，确认记录不再异常增长。

真正的解决方案是停止重复生成，而不是定期把 url_rewrite 清空。