magento url重写没用？

我想提两点。

第一点。 我注意到一种奇怪的行为，很可能是一只虫子。 我配置了一个新的Magento干净实例（没有其他模块，所以从头开始）和一个空数据库。 我在根目录下创建了3个类别。 和3种产品，每个类别一种。 比如：

Cat 1
+ Prod 1
Cat 2
+ Prod 2
Cat 3
+ Prod 3

my-cat/camera-112-p.html

如果我更改类别的顺序，使“第3类”在“第2类”之前，如下所示：

Cat 1
+ Prod 1
Cat 3
+ Prod 3
Cat 2
+ Prod 2

camera-1.html
camera-2.html

UPDATE camera-1.html  => camera-3.html 
UPDATE camera-2.html  => camera-4.html 

我只需要从类别管理屏幕上拖放“Cat 3”到“Cat 2”的上方。 所以cat2和cat3的“订单”号实际上是交换的

但是url索引过程会重新索引所有类别的所有产品（url重写索引）！ 我分析了SQL日志，它实际上对数据库中的每个产品都进行了插入。 我看到了“产品1”、“产品2”和“产品3”的核心url重写中的insert

这是一个错误，因为“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”表示未插入任何内容） 免费处理每个产品，并尝试插入可能已经存在的内容，这是浪费时间

第二点 我发现了另一个bug/奇怪的行为。 如果我有两个同名的产品（可能发生），那么url键是相同的（默认情况下）。 顺便说一句，在复制产品以创建新产品时，默认情况下url键也是相同的

因此，重新编制索引的过程变得疯狂。 例如，两款名为“camera”的产品的url重写如下：

Cat 1
+ Prod 1
Cat 3
+ Prod 3
Cat 2
+ Prod 2

camera-1.html
camera-2.html

UPDATE camera-1.html  => camera-3.html 
UPDATE camera-2.html  => camera-4.html 

我同意这一点。 但是，如果现在我重新索引所有内容，它会变得疯狂。 它将更改这些产品的url重写（即使我没有更改与这些产品相关的任何内容）。 它将更新以下两种产品：

Cat 1
+ Prod 1
Cat 3
+ Prod 3
Cat 2
+ Prod 2

camera-1.html
camera-2.html

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个无用的插入都是徒劳的。 如果我再次重新编制索引，我会等待结束，并立即重新编制索引，然后Magento执行4次更新、4次插入等操作。 为什么？reindex:-）之间的任何数据都没有任何更改

如果你有5000个同名产品（像我一样），那么它是10000个更新和10000个（真实的）免费插入。。。 核心url重写的大小每天不断增加。死亡率极高 注：我有一个很好的理由拥有5000种名称完全相同的产品：-） 不管我的理由是什么，这看起来很奇怪

你已经检查过了吗？ 启用新安装的magento和日志文件后，很容易检查

最后一件事是，为什么我们需要核心url重写表？ 这是magento性能问题的主要原因之一

4行php代码+htaccess url重写将完成完全相同的工作，不需要数据库表（自定义url重写或CMS页面除外）。 一种方法用于动态生成产品的url（如果需要，基于名称和类别），另一种方法用于生成类别的url。 然后访问重定向。 您只需要在url中输入一个关键字，就可以知道它是指向产品还是类别的链接，以及它的ID。 比如：

Cat 1
+ Prod 1
Cat 2
+ Prod 2
Cat 3
+ Prod 3

my-cat/camera-112-p.html

htacces URL rewrite检测到它是指向产品的链接（因为-p.htm），它从URL（112）中获取产品id，并相应地重定向用户。 拥有产品ID可能看起来很难看，或者是SEO的问题，但我不这么认为（没有你读到的那么糟糕）。 它必须与巨大的利益相平衡： 1） 再也没有大桌子了 2） 无需重新索引此表（这需要几个小时，比如8个小时，有很多magento网站）。这个过程会导致很多超时问题、锁定等

至少通过一个选项（或模块）可以做到这一点。 还请注意，您甚至不需要关心永久重定向，因为链接中的内容（文本）并不重要！身份证很重要

它存在吗？如果是的话，我肯定会买它来对这个复杂的混乱机制说“再见”（有bug）

如有任何反馈，将不胜感激。 （特别是如果您发现magento的行为方式有任何合理性，考虑到与使用/管理此表相关的低性能，因此必须高度赞赏rational:-）

谢谢

---

Rod

第1点和第2点似乎已经解决，请参见EE 1.13.0.2的注释（今天发布，即将发布CE 1.7）：

但是，你的一些观点值得一提

• 为什么URL重写是这样工作的？因为这就是它们的工作方式-这就是它们的创建/发展方式，包括当两个产品具有相同的

  url\u键时您注意到的赛车重写错误

• 基于大量的基准测试和经验，我可以说，

  core\u url\u rewrite

  表不是“Magento性能不佳的主要原因”。不过，毫无疑问，重新编制索引的过程可能会很糟糕
• URL重写表通常对于自定义重写是必需的。建议操纵服务器配置文件（例如Apache <代码> .HTAccess < /代码>）来添加重写没有考虑到MaMeNTO是一个可以在没有直接开发人员知识的情况下修改和扩展的应用程序（例如，由商店所有者）。
• 使用漂亮的URL

  mod_rewrite

  模式的建议对于任何关注SEO的商店都是站不住脚的，我向你保证