当业务数据量较大时，有时sql查询会变慢，影响数据的展示和用户体验，所以我们在编写sql时要尽量考虑到数据量较大的场景，以免影响后续的使用，但有的时候计划赶不上变化，这个时候我们不得不进行sql语句优化
原始sql:
SELECT
b.store_id AS `storeId` ,
b.goods_id AS `goodsId` ,
b.goods_info_id AS `goodsInfoId` ,
b.sale_price AS `salePrice`
FROM
brand_store_goods b
LEFT JOIN goods g ON b.goods_id = g.goods_id
WHERE
b.del_flag = 0
AND g.del_flag = 0
AND g.audit_status = 1
AND(g.added_flag = 1 OR g.added_flag = 2)
AND b.supplier_added_flag = 1
GROUP BY b.store_id , b.goods_id
limit 0,10
explain分析sql
当发现一条sql的查询耗时较多时，首先我们要判断sql语句的执行效率，explain后发现都是全表扫描，还没有索引。因为虽然分页，但使用了group by关键词，mysql还是会进行全表扫描
explain结果
查询耗时
建立索引
首先我们在group by的字段上添加上索引，然而发现速度并没有什么变化，这个时候我们看sql是先left join再group by的，那是不是和sql的执行顺序有关呢
sql执行顺序
FROM
ON
JOIN
WHERE
GROUP BY
WITH CUBE or WITH ROLLUP
HAVING
SELECT
DISTINCT
ORDER BY
TOP
这里得知，Mysql 是先执行关联表然后再进行条件查询的最后再分组,那么想想这SQL的条件查询和分组都只是一个表的，关联后数据就变得多了，这时候再进行条件查询和分组是不是有点没必要，我们可以尝试一下提前进行分组和条件查询，实现方法就是子查询联合关联查询
SELECT
A.store_id ,
A.goods_id ,
A.sale_price
FROM
(
SELECT
store_id ,
goods_id ,
sale_price
FROM
brand_store_goods
WHERE
del_flag = 0
AND supplier_added_flag = 1
GROUP BY
store_id ,
goods_id
) A
LEFT JOIN goods g ON
A.goods_id = g.goods_id AND g.del_flag = 0
AND g.audit_status = 1
AND(g.added_flag = 1 OR g.added_flag = 2)
LIMIT 0,10
explain再来看下
explain结果
查询耗时
看起来是优化了不少，但是其实数据量目前还没有很大，是不是可以继续从其他地方下手优化呢，比如left join，left join优化比较重要的两点是：1、小表驱动大表 2、右表的条件列一定要加上索引（主键、唯一索引、前缀索引等），最好能够使type达到range及以上（ref,eq_ref,const,system）
现在我们在原始sql的基础上，对右表（brand_store_goods）条件列goods_id上加上索引
explain结果
看到这波分析心里踏实了一些，看下耗时
查询耗时
这个速度基本比较满意了，不过像刚才说的，目前的数据量其实还没有达到几十万甚至百万级，后续肯定还需要进一步优化，不过我认为其实一开始完全可以在数据库表设计层面规避掉group by的使用，拆成两张表去存储，不过这也是后话了
