一 简介:聊聊group by的分组
二 explain体现
extra下
1 using tempoary
2 using tempoary && using filesort
3 using filesort
4 none
三 实现方式
1 定义
GROUP BY 实际上也同样会进行排序操作，而且与ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作,所以group by同样可以利用到索引
2 实现方式
使用松散（Loose）索引扫描实现 GROUP BY
1 单一表查询
2 Group by中只有最左前缀列，没有其他列
3 只支持max和min聚合，而且，要聚合的列必须是group by中列所在的索引(未测试)
4 未被group by引用的索引其他部分必须是常量（不理解）
5 不支持前缀索引。
eg
-- 因为聚合函数不是max或者min
SELECT c1, SUM(c2) FROM t1 GROUP BY c1;
-- 因为不符合最左前缀原则
SELECT c1, c2 FROM t1 GROUP BY c2, c3;
-- 查询涉及到了索引的一部分，紧跟group by中的列，但是没有常量等值语句，加上 WHERE c3 = const就好了
SELECT c1, c3 FROM t1 GROUP BY c1, c2;
2 使用临时表实现 GROUP BY
处理过程 通过where索引过滤 然后放置在临时表中再进行分组+排序
四 优化
1 尽量使用group by 的分组利用到联合索引
2 尽量添加order by null避免filesort
五 order by 使用场景解析
select * from table order by a1 当a1有索引的时候是可以利用到索引的
select * from table where a1=1 order by b1 当a 和 b为联合索引且a为最左的时候 是可以利用到索引的
select * from table order by a1 desc, b1 利用8.0的特性创建制定顺序的联合索引是可以的,其他情况下是不能利用到索引,因为联合索引只能按照一个顺序进行查找
select * from table order by a1,b1 当a和b为联合索引时是可以利用到索引的
select * from table where a1 > n order by a1 这种情况下根据数据量的分布可能会利用到icp特性或者应用不到索引
select * from table where a1 = n and b1 > n order by b1 这种情况下可能会遇到ICP特性
select * from table group a1 order by b1 这种情况下不能利用索引
相关排序参数 sort_buffer_size 先利用这个参数内存,只有内存不够了才会在磁盘形成临时文件
六 order by 与分页操作
select * from table where a = b = order by id limit 10
现象 通过explain 走的是ID主键 奇怪现象 asc 与 desc 相差速度很大,但是explain确是相同
分析 通过explain分析可知,执行顺序为 先根据order by进行排序 然后再进行条件过滤 最后分页取操作. asc与desc执行速度的不同其实也可以推测. 那么就是结果集的数据都集中在正向而不是反向.那么这样desc 和asc的速度不一样就可以得知了.而limit 小结果集的加入让sql优化器更倾向于order by 索引
解决方法: 1 order by 的排序项最好能参与到 where条件过滤中,即是联合索引的一部分 2 调大 limit 结果集(根据业务决定) 3 采用延迟join