时间:2021-07-01 10:21:17 帮助过:48人阅读
- SELECT
- pg.product_goods_id,
- pg.product_id,
- pg.pdt_code,
- pg.pdt_name,
- pg.brand_name,
- pg.reference_price,
- pg.deposit,
- pg.sale_status,
- pg.is_delete,
- pg.create_date,
- pg.create_operator,
- pg.update_date,
- pg.update_operator,
- si.shop_id,
- si.shop_name,
- pg.goods_img_url,
- pg.is_bargain,
- pg.qr_code_url,
- (
- SELECT
- COUNT(*)
- FROM
- product_attention pa
- WHERE
- pa.product_goods_id = pg.product_goods_id
- AND `status` = 0
- ) AS laud,
- pc.category_name,
- pg.is_experience,
- pg.deposit,
- pg.buy_type,
- pg.content,
- pg.assure_flag,
- pg.market_price,
- pg.qty_cnt,
- pg.sales_cnt
- FROM
- product_goods pg
- LEFT JOIN shop_info si ON si.shop_id = pg.shop_id
- LEFT JOIN product_category pc ON pc.category_id = pg.category_id
- WHERE
- si.market_id IN (1, 2, 3, 12, 13)
- ORDER BY pg.update_date DESC , pg.product_goods_id DESC
- LIMIT 0,
- 20;
问题1,加上如下的子查询,比较慢
- (
- SELECT
- COUNT(*)
- FROM
- product_attention pa
- WHERE
- pa.product_goods_id = pg.product_goods_id
- AND `status` = 0
- ) AS laud,
这里加上去就有点慢,有什么优化办法么,询问有啥方法?
原blog地址:http://blog.csdn.net/mchdba/article/details/49667417,未经原作者同意,谢绝转载。
C:\Users\Administrator\Pictures\1105\e1.jpg
从中可以看到,pg表中用到了临时表空间也用到了filesort,这个点比较麻烦了。
、pa.jpg
、si.jpg
、pg.jpg
几个表的数据量都不大,product_goods 6w多条,其他3千多条。不应该这么慢的。
我猜猜可能是order by引起的,我让去掉order by之后,他说比较快,但是这个order by不能轻易去掉,因为这是也许需要。但是order by字段里面有 product_goods_id。
分析到引起蛮的order by以及子查询里面都有product_goods_id字段,而且这个字段是pg表的主键,这么可以强制使用主键索引而不走shop_id的索引,我让他采用product_goods pg force index(PRI) 强制使用主键索引,我这样想,主要是因为这个语句的子查询用的是主键关联,但是explain的时候用的是shop_id的索引,我就怀疑是走了这个shop_id的索引导致的。如果不走这个shop_id字段的索引,直接走主键id既然兼顾到了join表链接又兼顾到了子查询了。
结果,他测试了后,发现快了许多,问题解决,expain结果如下ok.jpg所示,已经没有using temporary这一项了。