mysql group by 查询慢_mysql定位和优化慢查询的方案

是否遇到过这样的场景：因为一条sql查询耗时太长，降低用户体验；或者面对sql结合业务，不知道怎么写才能更高效地输出结果？今天帝都的雁为大家分享一下如何在千万级的数据量下输出高效的sql语句。

(PS:需要有mysql执行流程原理的理论基础，可参考我的另一篇博文《mysql查询和修改的底层原理》)

一、数据结构

Mysql之所以可以快速地吞吐，很大程度上依赖于其底层的数据结构--B+树。

首先我们先了解一下几种索引可选择的数据结构。

1、Hash

数据按照hash算法进行散列分布，通过hash算法，可以快速定位到具体的数据存放地址。但由于其散列分布带来的致命缺陷(范围查询不友好)，实际开发中，很少有表使用这种索引。

2、二叉树

二叉树存放数据时，需要先指定根节点，然后进行比值，将索引值存放在左子树(比父节点小)或右子树(比父节点大)上。二叉树缺点很明显，如果根节点固定的话，那么数据很有可能失去平衡。比如自增ID如果按照二叉树去存放索引，那么本质上就是一条链表，时间复杂度也变为o(n)。

3、平衡二叉树

在二叉树的基础上，增加了旋转功能来使整棵树达到平衡(左右子树高度差的绝对值不超过2)。HashMap8的数据结构红黑树也是一种特殊的平衡二叉树。这种数据结构看似可以维护平衡，但也仅仅是比链表好一点。由于其每个节点只能存放一个索引值，在数据量庞大的情况下，树的高度将会是一个无法直视的数字。想要找到树底层的数据，可能要进行的时间复杂度为o(log(n))，而且每次查找都是一次磁盘的IO，这种频繁IO必然牺牲性能。

4、B树

为了解决降低树的高度，B树开始支持单个节点存放多个索引值(16KB)。这样一来，树的高度就会几何式降低。B树的缺点在于，节点上不仅存放索引值，也同时存放着索引对应的数据(或者数据的地址，这要依照于索引是否是聚簇索引)。试想，如果索引对应的数据比较大，那么单个节点存放的索引个数就会变小，使得树的高度，不再那么理想化。而且InnoDB存储引擎以页的方式对数据IO，也就是说，一次IO会把这一个节点上的数据都加载出来，可是实际需要的可能只是其中几个索引值，那么其他的索引值对应的数据也加载到内存，是不是增加了内存的消耗？