当我们的约会平台在线运行一段时间时，为了让平台用户搜索朋友，他们建议并介绍对搜索结果感兴趣的朋友。目前，我们将分析有关用户行为的数据。他建议他有兴趣的朋友。
在这里，我使用最简单的SQL分析方法：用户的统计数据检查过去的朋友的性别和年龄，并根据其年龄获得统计结果。基于此结果，性别最高的朋友和年龄的朋友建议用户。
因此，假设我们现在有一个详细的表供用户浏览朋友。表的表结构如下：
为了促进使用SQL统计信息并查看上面的表结构，我减少了用户的性别和年龄领域。
让我们看一下此表中的记录：
现在，与上面的表结构和表记录相结合，以用户为例。由用户查看的用户查看的女性用户的数量：
统计结果如下：
可见的：
因此，用户对20岁的女性用户更感兴趣，并且可以推荐更多20岁的女性用户。
如果此时，T_USER_VIEW表的记录达到1000万，则大概该SQL的查询效率将直接删除。为什么？有什么方法可以优化？
如果您想知道原因，则必须查看此SQL执行的过程？
让我们先看一下这个SQL：
执行上述句子后，我们将获得以下结果：
本列中有三个，这三个代表“指南”中的句子。
在这三个阶段中出现了一个术语：。我在“ mySQL计时：100W？300W？500W？它是不对的！”一篇文章说，这是MySQL连接线程可以独立访问和处理的记忆区域。那么这个临时手表是什么样的？
让我首先讨论此MySQL的临时表，然后在引言中与上述三个阶段结合使用SQL的执行过程。
让我们看一下“简介”中包含组字段和统计字段的声明中的SQL。这两个字段是该SQL中统计的一部分。如果我们要执行这样的统计数据并巩固结果，则必须是内存或磁盘区域的第一个统计数据的结果。然后，下一个统计数据是通过此结果进行的。处理区域称为MySQL。
刚刚提到的中间结果可以放在内存中，或者可以将此结果放在磁盘上。因此，MySQL：Harmony中有两个临时表。
内存的内存临时表是什么？当早期数据的数量不是很大时，以存储数据包和统计字段为例。然后，基本上，内存可以完全存储与组和统计字段相对应的所有值。此存储大小由参数确定。这次，此存储的内存区域，mySQL称为临时内存表。
目前，也许您已经觉得MySQL存储在内存中的过渡期，并且保证了性能。但是，在“ MySQL时序计时：100W？300W？500W？它是不对的！”中，我提到频繁的内存访问将生成片段。为此，MySQL设计了一套新的内存分配和释放机制，减少甚至避免暂时的内存片段表，并增加内存临时表的利用。
目前，您可能会想：“为什么我调整sort_buffer_size，并发量很大，并且查询排序放慢了狗？”“在文章中，我谈到了用户模式的内存分布：PTMALLOC和TCMALLOC，无论哪种分销商，其作用都是为了避免用户的过程经常从Linux内核申请存储空间，从而使CPU经常在用户模式和内核状态之间经常使用，以影响内存访问的效率。使用它们来解决内存利用的问题。为什么MySQL必须自己进行设置？
也许MySQL的作者感到，无论哪种内存分销商，其实现都太复杂了。这些复杂性将影响MySQL用于内存处理的性能。因此，MySQL本身已经意识到了一组内存分布机制：它的内存处理机制相对简单，并且内存临时表的分布是采用这种方式。
下面，我以指南中的SQL为例，以详细说明组统计信息如何使用内存分配和释放机制？
mem_root我们首先查看结构，设计相对简单，主要包括这些部分，如下图所示：
免费：一个 - 道路链接列表，链接列表中的每个单元被调用，并且存储了免费内存区域。每个包含3个元素：
如上图所示，其位于其位置的行是链接列表。连接到链接列表中每个箭头的零件是，在中间，每个箭头之间的箭头是指针
二手：一个 - 道路链接列表，链接列表中的每个单元被调用，并且内存存储在内存区域中。同样，每个包含上述3个元素
min_malloc：在控制剩余空间时从链接列表中删除，然后将其添加到链接列表中
block_size：对应于内存的大小
block_num：管理数量
first_block_usage：在链接列表中不满足应用程序空间大小的第一个次数
pre_alloc：整体发布时
让我以“指南”中的组统计信息为例。看到如何分配内存？
分发
以下是基于引言中的组统计信息为例。让我们看一下它如何发布记忆？
Image-20210323233158459.png
如上所示，发行内存的过程如下：
通过解释内存分配和发布，我们发现的内存管理方法是在每个顶部连续分配的。内部片段基本上是在每个片的尾部，由成员变量控制，但是该值是在代码中写入的，该值足够灵活以至于足够灵活。从其应用程序中较大的内存，介质的值越小。然后，内存利用率越高，片段越少，否则就越碎片。这是MySQL的记忆分布的缺陷。
该值对应于决策值的数据包和统计字段的磁盘临时表，然后MySQL将使用磁盘存储这些值。在存储值的此磁盘区域中，MySQL称其为临时磁盘。
我们都知道，磁盘访问的性能必须比内存访问的性能要差得多，因为将生成磁盘io，因此一旦必须将分组和统计字段写入磁盘，性能就相对较差，因此我们尝试尽可能地调整。LARGE参数使组和统计字段在内存中的过渡中进行处理。
无论是使用内存临时表还是临时磁盘表，临时表在组和统计字段的过程中都是相同的。在“简介”中，我提到“简介”中的SQL需要知道原理SQL执行。，请参阅下文：
通过简介中SQL的执行过程的说明，我们发现该过程已经完成了4个部分：IDX_USER_VIEWED_USER，CLUSTER_INDEX，termorary和sort_buffer。与使用tempory，sort_buffer相对应的对应于使用filesort。
目前，我们可以如何优化此SQL？
由于此SQL执行需要4个部分，因此我们可以删除最后两个部分，即删除tempory和sort_buffer吗？
答案还可以。我们只需要在SQL中的表中添加以下索引：
您可以自己尝试一下！Kangkang有哪些更改！
本章围绕简介SQL中的组统计数据进行了旋转。通过分析SQL的执行阶段并结合临时表的结构，进一步分析了SQL的详细执行过程。统计学以及分类数据包和统计字段。
当然，如果无法避免临时表，请尽量增加磁盘临时表统计分组字段。
为什么新索引可以避免在小组字段，分类组和统计领域上的临时表统计数据？
提示：结合索引原则。