Mysql Magento慢速类别计数查询

我们最近对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表，使用了临时索引；使用文件排序。但这是真的吗

如果是，我如何识别缺少的索引，其次，我将如何在Magento中应用此索引

---

我知道这也与选择COUNTDISTINCT count\u table.product\u id和按count\u table.category\u id分组有关，因为删除这些部分会导致更快的查询，而不需要预期的信息

此问题是两个内部联接引用同一个表catalog\u product\u flat\u 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表上的第二个联接，并将其称为catalog_product_flat_1_2，但出现问题的原因是它没有在联接条件中识别不正确的表别名

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

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

由于第二个连接引用了正确的表别名，查询时间从3s缩短到20ms

---

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

文件排序可能适用于group by。要解决这个问题，你没什么办法。我在这里寻找其他东西，但你的解释对我解决问题有点帮助