我们最近对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 表格使用 Using temporary; Using filesort . 但这是真的吗？
如果是，我该如何识别缺失的索引，其次，我该如何在magento中应用这个索引？
我知道这和选择 COUNT(DISTINCT count_table.product_id) 和分组依据 count_table . category_id 因为删除这两个部分中的任何一个都会导致更快的查询（只是没有预期的信息！）。
1条答案
按热度按时间osh3o9ms1#
这个问题是二者共同作用的结果
inner join是指同一张表，catalog_product_flat_1，但联接的第二个示例上的联接条件引用了第一个示例中的表：尽管这个问题引用了magento，但实际上这与zendèdb和定义连接的方式有关。
给定zend\u db\u select对象，可以创建如下连接：
你第一次这样做没关系，但如果你第二次这样做
joinInner函数将智能地标识catalog_product_flat_1然后叫它catalog_product_flat_1_2，但发生此问题的原因是它没有在联接条件中标识不正确的表别名。解决此问题的方法是通过提供名称关联来显式设置表别名，如下所示：
由于第二个连接引用了正确的表别名，查询时间从
3s至20ms.magento两次添加内部连接是另一回事，但一旦配置正确，就不会影响性能。