mysql - 如何让 Magento 更快地保存产品？

Question

此行以下的所有内容都已过时。 Magento 只是很慢，仅此而已。

---

如 https://stackoverflow.com/questions/12580828/magento-saving-product-is-extremly-slow-but-profiler-shows-it-only-takes-1sec/12583078#12583078 所述，Magento 非常慢

由于在 HostGator 上缺乏 root 权限而苦苦挣扎之后，我最终自己分析了 Magento 调用。

这是其中一个结果:

蓝色:计时 1982878436 Mage_Sales_Model_Mysql4_Quote 开始 <- 这是在进入 Mage_Sales_Model_Mysql4_Quote 的save 方法时记录的。

蓝色:计时 1982878436 Mage_Sales_Model_Mysql4_Quote 46 <- 退出时记录。

数字 1982878436 是作为调用 ID 生成的随机数。而数字 46 是以秒为单位的时间。

2012-09-26T06:36:16+00:00 DEBUG (7): Blue: timing 1982878436 Mage_Sales_Model_Mysql4_Quote begin
2012-09-26T06:36:18+00:00 DEBUG (7): Blue: timing 645597828 Mage_Log_Model_Mysql4_Visitor begin
2012-09-26T06:36:18+00:00 DEBUG (7): Blue: 645597828 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:36:18+00:00 DEBUG (7): Blue: timing 645597828 Mage_Log_Model_Mysql4_Visitor 0
2012-09-26T06:36:18+00:00 DEBUG (7): Blue: timing 1712949075 Mage_Sales_Model_Mysql4_Quote begin
2012-09-26T06:36:24+00:00 DEBUG (7): Blue: timing 2103820838 Mage_Sales_Model_Mysql4_Quote begin
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: timing 1999314779 Mage_Log_Model_Mysql4_Visitor begin
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: 1999314779 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: timing 1999314779 Mage_Log_Model_Mysql4_Visitor 0
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: timing 504509596 Mage_Sales_Model_Mysql4_Quote begin
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: timing 1887845167 Mage_Log_Model_Mysql4_Visitor begin
2012-09-26T06:36:56+00:00 DEBUG (7): Blue: timing 1887845167 Mage_Log_Model_Mysql4_Visitor 0
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 1887308594 Mage_GoogleOptimizer_Model_Mysql4_Code begin
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 1887308594 Mage_GoogleOptimizer_Model_Mysql4_Code 0
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: 504509596 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 504509596 Mage_Sales_Model_Mysql4_Quote 6
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: 1982878436 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 1982878436 Mage_Sales_Model_Mysql4_Quote 46
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: 1712949075 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 1712949075 Mage_Sales_Model_Mysql4_Quote 44
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: 2103820838 Varien_Db_Adapter_Pdo_Mysql
2012-09-26T06:37:02+00:00 DEBUG (7): Blue: timing 2103820838 Mage_Sales_Model_Mysql4_Quote 38

正如我们所见，1982878436、1712949075、2103820838 是并行调用的，每个调用都需要几十秒才能完成。我怀疑这三个调用之间存在一些锁定问题，使它们相互等待。有时当我保存产品时，Magento 甚至会报告 action being failed，因为 MySQL 因死锁而失败。

有人对此有任何想法吗？

Answer 1

当在 IN 中运行查询时，MySQL 总是使最外层的表领先。

这意味着这个查询:

    UPDATE {$this->getTable('sales/quote')} SET trigger_recollect = 1
    WHERE entity_id IN (
        SELECT DISTINCT quote_id
        FROM {$this->getTable('sales/quote_item')}
        WHERE product_id IN (SELECT DISTINCT product_id FROM {$this->getTable('catalogrule/rule_product_price')})

将必须扫描 sales/quote 中的每条记录，并根据 sales/quote_item 检查它，而后者又必须根据 catalogrule 检查每条匹配的记录/rule_product_price.

如果 sales/quote 中的记录明显多于子查询返回的记录，这会很慢。

您可能希望将其重写为连接:

UPDATE  {$this->getTable('catalogrule/rule_product_price')} crpp
JOIN    {$this->getTable('sales/quote_item')} sqi
ON      sqi.product_id = crpp.product_id
JOIN    {$this->getTable('sales/quote')} sq
ON      sq.entity_id = sqi.quote_id
SET     sq.trigger_recollect = 1

这样，优化器可以选择哪个表作为前导(当每个连接字段都被索引时，它应该是最小的表)。