【发布时间】：2013-08-16 10:00:15
【问题描述】：
我想提两点。
第一点。 我注意到一个奇怪的行为，很可能是一个错误。 我配置了一个新的 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 options 是关于永久重定向的。
所以 2 次无用的更新和 2 次无用的插入都是徒劳的。 如果我再次重新索引，我等待结束，并立即重新索引，然后 Magento 进行 4 次更新、4 次插入等。 为什么？？重新索引之间的任何数据都没有任何变化:-)
如果您有 5 000 个同名产品（就像我一样），那么它就是 10 000 次更新和 10 000 次（真实）插入... core_url_rewrite 的大小每天一次又一次地增加。饱和度极高 注意：我有充分的理由拥有 5 000 个名称完全相同的产品 :-) 不管我的理由是什么，这看起来很奇怪。
你已经检查过这个了吗？ 全新安装的 magento 和启用的日志文件很容易检查。
最后是，为什么我们需要 core_url_rewrite 表？ 这是 magento 性能问题的主要原因之一！
4 行 php 代码+htaccess url 重写将完成完全相同的工作，不需要为此使用 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 网站）。这个过程可能会导致很多超时问题，锁定等。
至少这应该可以通过一个选项（或模块）来实现。 另请注意，您甚至不需要关心永久重定向，因为链接中的内容（文本）无关紧要！只是 ID 很重要。
它存在吗？如果是的话，我肯定会买它来对这种复杂的混乱机制说“再见”（有错误）
任何反馈都将受到高度赞赏。 （特别是如果您发现 magento 的行为方式有任何合理性，考虑到与使用/管理此表相关的较差性能，因此必须高度赞赏合理性:-)）
谢谢 棒
【问题讨论】：
标签： magento url-rewriting indexing