列表IN()的比较。 在很多的数据库系统中，IN()完全等同于多个OR条件的子句，因为这两者是完全等价的。但是在MySQL中，它将IN()列表中的数据先进行排序，然后通过二分查找的方式来确定列表中的值是否满足条件，这是一个O(log n)复杂度的操作，等价转换为OR查询的复杂度为O(n)。对于IN()列表中有大量取值的时候，MySQL的处理速度会更快。
上面列举的并不是MySQL优化器的全部，MySQL还会做其他大量的优化，因此我们完全没有必要尝试“自己会比优化器更加聪明”，这样不仅会让查询更加复杂而难以维护，并且最终收益可能为0.让优化器按照自己的方式正常工作即可。
但是如果能够确认优化器给出的并不是最佳选择，并且清除背后的原理那么也可以尝试帮助优化器作进一步的优化。比如在查询中添加hint提示，也可以重写查询或者重新设计库表结构。
数据和索引的统计信息MySQL在服务器层有查询优化器，但是没有保存数据和索引的统计信息。统计信息由存储引擎实现，不同的存储引擎可能会存储不同的统计信息或者按照不同的格式存储统计信息。
MySQL如何执行关联操作MySQL中的“关联（join）”比一般意义上理解的更加广泛。总的来说，MySQL认为任何一个查询都是一次“关联”——并不仅仅是一个查询需要用到两张表的匹配才叫关联。
以UNION查询为例MySQL先将一系列的单个查询结果放到一个临时表中，然后再重新读出临时表数据来完成UNION查询。
当前MySQL关联执行的策略如下：MySQL对任何关联都执行嵌套循环关联操作，即MySQL现在一个表中循环取出单条数据，然后再嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为止。然后根据各个表匹配的行，返回查询中需要的各个列。MySQL会尝试在最后一个关联表中查找到所有匹配的行，如果最后一个关联表无法找到更多的行以后，MySQL就会返回上一层次关联表，看是否能够找到更多的匹配记录，以此类推迭代执行。
执行计划和很多其他关系型数据库不同，MySQL并不会生成查询字节码来执行查询。MySQL生成查询的一棵指令书，然后通过存储引擎执行完成这棵指令书并返回结果。最终的执行计划包含了重构查询的全部信息
关联查询优化器MySQL优化器最重要的一部分就是关联查询优化，它决定了多个表关联时的顺序。通常多表关联时，可以有多种不同的关联顺序来获得相同的结果。
关联查询优化器则通过评估不同顺序时的成本来选择一个代价最小的关联顺序。它会遍历每一个表然后逐个做嵌套循环计算每一棵可能的执行计划树的成本，最后返回一个最优的执行计划。
然而，如果有超过n个表的关联，那么需要检查n的阶乘种关联顺序。这被称为可能的执行计划的“搜索空间”，搜索空间的增长速度非常快，如果我们需要关联10个表，那么共有3628800种不同的关联顺序。
当搜索空间非常大时，优化器会选择使用“贪婪”搜索的方式查找“最优”的关联顺序。有时候，各个查询的顺序是不能随意安排的，比如左连接等，这时候关联优化器就可以根据这些规则大大减少搜索空间。
排序优化无论如何排序都是一个成本很高的操作，所以从性能上看，应该尽可能避免排序或者尽可能避免对大量数据进行排序。
当不能使用索引生成排序结果的时候，MySQL需要自己进行排序。如果数据量小则在内存中进行，如果数据量大则需要使用磁盘，不过MySQL将这个过程统一称为文件排序（filesort），即使完全是内存排序不需要任何磁盘文件时也是如此。
如果需要排序的数据量小于“排序缓冲区”，MySQL使用内存进行“快速排序”操作。如果内存不够排序，那么MySQL会将数据分块，对每个独立的块使用“快速排序”进行排序，将各个块的排序结果存放在磁盘上然后将各个排好序的快进行合并，最终返回排序结果。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx