我想提两点。
第一点。 我注意到一个奇怪的行为，很可能是一个错误。我配置了一个新的 Magento 干净实例（没有其他模块，所以从头开始）和一个空数据库。我在根目录下创建了 3 个类别。和3个产品，每个类别一个。就像是：
Cat 1
+ Prod 1
Cat 2
+ Prod 2
Cat 3
+ Prod 3
如果我更改类别的顺序，则“Cat 3”在“Cat 2”之前，如下所示：
Cat 1
+ Prod 1
Cat 3
+ Prod 3
Cat 2
+ Prod 2
我只需从类别管理屏幕中将“Cat 3”拖放到“cat 2”上方即可。所以 cat2 和 cat3 的“订单”号实际上是交换的。
但是 url 索引过程会重新索引所有类别的所有产品（URL REWRITE 索引）！我分析了 SQL 日志，它实际上对数据库中的每个产品都进行了 INSERT。我在 core_url_rewrite 中看到插入“Prod 1”、“Prod 2”和“Prod 3”。
这是一个错误，因为“Cat 3”保持相同的父类别，所以：1）不需要重写“Cat 3”内的产品（产品名称没有改变，类别名称没有改变！！ ) 2) 没有必要重写链接到其他类别的产品
实际上，通过选择，我可以看到 core_url_rewrite 表的行是相同的（肯定没有更改名称！并且产品与产品上方的任何类别之间没有关联！）
这是我在移动类别时从日志文件中看到的一个 SQL 查询：
SQL: INSERT INTO `core_url_rewrite` (`store_id`,`category_id`,`product_id`,`id_path`,`request_path`,`target_path`,`is_system`) VALUES (?, ?, ?, ?, ?, ?, ?) ON DUPLICATE KEY UPDATE store_id = VALUES(`store_id`), category_id = VALUES(`category_id`), product_id = VALUES(`product_id`), id_path = VALUES(`id_path`), request_path = VALUES(`request_path`), target_path = VALUES(`target_path`), is_system = VALUES(`is_system`)
BIND: array (
0 => '1',
1 => NULL,
2 => '4',
3 => 'product/4',
4 => 'testun.html',
5 => 'catalog/product/view/id/4',
6 => 1,
)
AFF: 0
TIME: 0.0005
实际上，更糟糕的是，它插入了已经存在的行，所以它实际上并没有插入任何东西。插入失败（可以看到“AFF: 0”表示什么都没有插入） 白白处理每个产品是浪费时间，尝试插入可能已经存在的东西！
第二点 我发现了另一个错误/奇怪的行为。如果我有 2 个具有相同名称的产品（可能会发生），那么 url 键是相同的（默认情况下）。顺便说一句，当您复制产品以创建新产品时，默认情况下 url 键也是相同的。
所以重新索引过程变得疯狂。例如，名称为“camera”的 2 个产品的 url 会像这样重写：
camera-1.html
camera-2.html
我没问题。但是，如果现在我重新索引所有内容，它就会变得疯狂。它会改变那些产品的 url 重写（即使我没有改变任何与这些产品相关的东西）。它将像这样更新 2 个产品：
UPDATE camera-1.html => camera-3.html
UPDATE camera-2.html => camera-4.html
如果启用了设置，则插入重定向（因此以前的链接不会丢失），例如
INSERT camera-1.html , camera-3.html ,RP
INSERT camera-2.html , camera-4.html , RP
RP 选项是关于永久重定向的。
所以 2 次无用的更新和 2 次无用的 Insert 是徒劳的。如果我再次重新索引，我等待结束，然后立即重新索引，然后 Magento 进行 4 次更新、4 次插入等。为什么？重新索引之间的任何数据都没有任何变化:-)
如果您有 5 000 个同名产品（就像我一样），那么它就是 10 000 次更新和 10 000 次（真正的）插入…… core_url_rewrite 的大小每天一次又一次地增加。饱和度非常高 注意：我有充分的理由拥有 5 000 种名称完全相同的产品 :-) 不管我的原因是什么，这看起来很奇怪。
你已经检查过这个了吗？全新安装的 magento 和启用的日志文件很容易检查。
最后一件事是，为什么我们需要 core_url_rewrite 表？这是magento性能问题的主要原因之一！
4 行 php 代码 + htaccess url rewrite 将完成完全相同的工作，不需要 DB 表（自定义 url 重写或 CMS 页面除外）。一种动态生成产品 url 的方法（如果需要，基于名称和类别）和一种生成类别 url 的方法。然后htaccess重定向。您只需要在 url 中添加一个关键字，就可以知道它是指向产品还是类别的链接，以及它的 ID。就像是：
my-cat/camera-112-p.html
htacces URL rewrite 检测到它是指向产品的链接（因为 -p.htm），它会从 url (112) 中获取产品 id 并相应地重定向用户。拥有产品 ID 可能看起来很难看，或者是 SEO 的问题，但我不这么认为（没有你读到的那么糟糕）。并且它必须与巨大的好处相平衡：1）不再有巨大的表 2）不需要重新索引这个表（这需要几个小时，比如 8 小时，有很多 magento 网站）。这个过程可能会导致很多超时问题，锁定等。
至少这应该可以通过一个选项（或一个模块）来实现。另请注意，您甚至不需要关心永久重定向，因为链接中的内容（文本）无关紧要！只是身份证很重要。
它存在吗？如果是的话，我肯定会买它来对这个复杂的混乱机制说“再见”（有错误）
任何反馈将不胜感激。（特别是如果您发现 magento 的行为方式有任何合理性，考虑到与使用/管理此表相关的较差性能，因此必须高度赞赏合理性:-)）
谢谢罗德