查询“创建排序索引”上的MySQL配置文件，使用总时间的75％

我们正在尝试弄清楚如何优化查询（大约100毫秒），并运行我们看到的Creating Sort Index使用75%总时间的配置文件。首先，创建排序索引的确切效果是什么？是磁盘/ IO吗？

其次，我们可以对查询本身进行任何优化吗？

SELECT r.`id`, 
       r.name, 
       r.public_uri, 
       rv.version, 
       rv.interpreter, 
       rv.notes, 
       rv.content, 
       r.added, 
       r.added_by, 
       r.modified, 
       r.modified_by, 
       r.public, 
       r.public_by
  FROM recipe_heads rh, 
       recipes r, 
       recipe_versions rv
 WHERE rh.recipe = r.`id` 
   AND rh.recipe_version = rv.`id` 
   AND r.`id` = rv.recipe
ORDER BY r.added DESC

说明：

对于庞大的查询，我们也有类似的问题。查询通常要运行数小时（最多7-8个），具体取决于数据库上400M行的负载。但是，我们的目标是实现组结果，例如从表组中选择col1，col2，col3，count（1），count（distcolt col4）1,2,3。

根本的问题与您的相同，因为在两种情况下，DB都在内部对结果进行排序（排序）。

• 创建排序索引的工作方式。在mysql网站上，它说：“线程正在处理使用内部临时表解析的SELECT。” 根据我对算法的理解，系统很可能会将数据拆分为多个块，从磁盘中逐个读取这些块，对各个块进行排序，再放回一些临时磁盘空间，依此类推。系统对所有块执行此操作，并最终执行合并排序。这涉及大量的读/写。

一种可能的解决方案是增加DB的内存（这样它可以创建更大的块，可以保留在内存中），或者如果您在其他地方有更大的内存，则可以通过从DB流传输来对解决方案进行编程。这可以在登录时完成。

通过编程，我可以将时间从平均2小时减少到7.5分钟。

“创建排序索引”是数据库根据“ order by”子句确定返回值的顺序。这里的主要限制因素是可用的CPU / CPU速度和内存带宽。直到数据已经全部存储在内存中，才进行排序，至少对于这么小的查询而言。如果您分析查询，是否看到等待任何资源？

至于使该查询更快，您可以考虑在“ r.added”上添加索引，因为根据您的解释，它看起来好像没有索引。