Question

我们最近已在Magento商店中进行了一些更改，从而触发了以下SQL的运行：

SELECT `count_table`.`category_id`, COUNT(DISTINCT count_table.product_id) AS `product_count` 

FROM `catalog_product_flat_1` AS `e`

INNER JOIN `catalog_category_product_index` AS `cat_index` ON cat_index.product_id=e.entity_id AND cat_index.store_id=1 AND cat_index.visibility IN(2, 4) AND 1

INNER JOIN `catalog_product_index_price` AS `price_index` ON price_index.entity_id = e.entity_id AND price_index.website_id = '1' AND price_index.customer_group_id = 0

INNER JOIN `catalog_product_index_eav` AS `brand_idx` ON brand_idx.entity_id = e.entity_id AND brand_idx.attribute_id = '135' AND brand_idx.store_id = 1 AND brand_idx.value IN('967')

INNER JOIN `catalog_product_flat_1` ON catalog_product_flat_1.entity_id=e.entity_id

INNER JOIN `catalog_product_flat_1` AS `catalog_product_flat_1_2` ON catalog_product_flat_1.entity_id=e.entity_id

INNER JOIN `catalog_category_product_index` AS `count_table` ON count_table.product_id = e.entity_id 

WHERE (e.status = 1) AND (catalog_product_flat_1.brand = '967') AND (catalog_product_flat_1.brand = '967') AND (count_table.store_id = 1) AND (count_table.category_id IN ('335', '334', '332', '339', '337', '943')) 

GROUP BY `count_table`.`category_id`;

此SQL需要花费几秒钟的时间来运行，并且如果大量用户一次访问同一页面，则服务器最终将在查询备份时陷入停顿状态。

运行EXPLAIN可以做到这一点：

1   SIMPLE  brand_idx   ref PRIMARY,IDX_CATALOG_PRODUCT_INDEX_EAV_ENTITY_ID,IDX_CATALOG_PRODUCT_INDEX_EAV_ATTRIBUTE_ID,IDX_CATALOG_PRODUCT_INDEX_EAV_STORE_ID,IDX_CATALOG_PRODUCT_INDEX_EAV_VALUE   IDX_CATALOG_PRODUCT_INDEX_EAV_VALUE 4   const   17  Using where; Using index; Using temporary; Using filesort
1   SIMPLE  count_table ref PRIMARY,IDX_CAT_CTGR_PRD_IDX_PRD_ID_STORE_ID_CTGR_ID_VISIBILITY,15D3C269665C74C2219037D534F4B0DC    IDX_CAT_CTGR_PRD_IDX_PRD_ID_STORE_ID_CTGR_ID_VISIBILITY 6   db.brand_idx.entity_id,const    1   Using where; Using index
1   SIMPLE  e   eq_ref  PRIMARY,IDX_CATALOG_PRODUCT_FLAT_1_STATUS   PRIMARY 4   db.brand_idx.entity_id  1   Using where
1   SIMPLE  cat_index   ref IDX_CAT_CTGR_PRD_IDX_PRD_ID_STORE_ID_CTGR_ID_VISIBILITY,15D3C269665C74C2219037D534F4B0DC    IDX_CAT_CTGR_PRD_IDX_PRD_ID_STORE_ID_CTGR_ID_VISIBILITY 6   db.brand_idx.entity_id,const    1   Using where; Using index
1   SIMPLE  catalog_product_flat_1  eq_ref  PRIMARY PRIMARY 4   db.brand_idx.entity_id  1   Using where
1   SIMPLE  price_index eq_ref  PRIMARY,IDX_CATALOG_PRODUCT_INDEX_PRICE_CUSTOMER_GROUP_ID,IDX_CATALOG_PRODUCT_INDEX_PRICE_WEBSITE_ID,IDX_CAT_PRD_IDX_PRICE_WS_ID_CSTR_GROUP_ID_MIN_PRICE    PRIMARY 8   db.brand_idx.entity_id,const,const  1   Using index
1   SIMPLE  catalog_product_flat_1_2    index   NULL    IDX_CATALOG_PRODUCT_FLAT_1_ATTRIBUTE_SET_ID 2   NULL    21529   Using index; Using join buffer (flat, BNL join)

对我来说，这暗示使用brand_idx的{{1}}表基于某处缺少索引。但这是真的吗？

如果是的话，如何确定丢失的索引，其次，我将如何在Magento中应用该索引？

我知道这还与选择Using temporary; Using filesort并按COUNT(DISTINCT count_table.product_id)分组。count_table有关，因为删除这两个部分中的任何一个都会导致查询更快（只是没有预期的信息！）。

Answer 1

此问题是由于两个inner join引用同一表catalog_product_flat_1的结果，但是第二个连接实例的连接条件从第一个实例引用了该表：

INNER JOIN `catalog_product_flat_1` ON catalog_product_flat_1.entity_id=e.entity_id

INNER JOIN `catalog_product_flat_1` AS `catalog_product_flat_1_2` ON **catalog_product_flat_1**.entity_id=e.entity_id

尽管该问题涉及Magento，但这实际上与Zend_Db和定义联接的方式有关。

鉴于Zend_Db_Select对象，您可以像这样创建联接：

$select->joinInner('catalog_product_flat_1', 'catalog_product_flat_1.entity_id = e.entity_id');

第一次执行此操作是可以的，但是如果第二次执行此操作，则joinInner函数将智能地标识catalog_product_flat_1表上的第二个联接并将其命名为{{ 1}}，但是会出现此问题，因为它无法在联接条件中识别出错误的表别名。

解决此问题的方法是通过提供名称相关性来显式设置表别名，如下所示：

catalog_product_flat_1_2

在第二个联接引用正确的表别名的情况下，查询时间从$select->joinInner(array('unique_table_alias' => 'catalog_product_flat_1'), 'unique_table_alias.entity_id = e.entity_id');减少到3s。

Magento两次添加内部联接的事实是另一回事，但是一旦配置正确，就不会影响性能。

Magento慢类别计数查询

1 个答案: