原标题：具体优化查询语句的指导原则小结果集驱动大结果集避免子查询

具体优化Query语句的指导原则

(1)多使用Profile；(2)永远用小结果集驱动大的结果集；(3)尽可能在索引中完成排序；(4)只取自己需要的Columns；(5)仅仅使用最有效的过滤条件；(6)尽可能避免复杂的Join和子查询。

具体优化Query语句的指导原则——永远用小结果集驱动大结果集

使用小表驱动大表，大表经过WHERE条件过滤之后返回的结果集更少的话也应该算为小表。

MySQL只有Nested Loop一种Join方式——MySQL的Join都是通过嵌套循环来实现的。驱动结果集越大，所需要循环就越多，那么被驱动表的访问次数自然也就越多。

Oracle中的Hash Join算法，小结果集驱动大的结果集同样是最优的选择。

优化Join Query最基本的原则就是“小结果集驱动大结果集”，通过这个原则来减少嵌套循环中的循环次数，以减少IO总量及CPU运算的次数。

具体优化Query语句的指导原则——尽可能在索引中完成排序

利用索引进行排序操作，主要是利用了索引的有序性。

具体优化Query语句的指导原则——只取出自己需要的Columns——网络传输

返回的数据都要通过网络数据包传回给客户端，取出的Column越多，须要传输的数据量会越大，不论是从网络带宽方面考虑还是从网络传输的缓冲区来看，这都是一个浪费。

具体优化Query语句的指导原则——只取出自己需要的Columns——排序算法——MySQL 4.1之前的算法

先将要排序的字段和可以直接定位到相关行数据的指针信息取出，然后在设定的排序区(通过参数sort_buffer_size设定)中进行排序，完成排序之后通过行指针信息取出所需的Columns，这种算法须要两次访问数据。

具体优化Query语句的指导原则——只取出自己需要的Columns——排序算法——MySQL 4.1的算法

一次性将所需的Columns全部取出，在排序区排序后直接将数据返回给请求客户端。改进算法只须访问一次数据，减少了大量的随机IO，极大地提高了排序Query语句的效率。

具体优化Query语句的指导原则——只取出自己需要的Columns——排序算法的比较

MySQL 4.1算法一次性取出并缓存的数据比MySQL 4.1之前的算法要多很多，如果将并不需要的Columns也取出来，就会极大地浪费排序过程所需要的内存。

具体优化Query语句的指导原则——只取出自己需要的Columns——排序算法相关设置

可以通过设置max_length_for_sort_data参数来控制MySQL选择第一种排序算法还是第二种。当取出的所有大字段总大小大于的设置时，MySQL就会选择使用第一种排序算法，反之，则会选择第二种。

具体优化Query语句的指导原则——只取出自己需要的Columns——尽量采用MySQL 4.1排序算法

为了尽可能地提高排序性能，当然应该使用MySQL 4.1排序算法，所以在Query中仅仅取出需要的Columns是非常有必要的。

具体优化Query语句的指导原则—— 仅仅使用最有效的过滤条件

WHERE子句中的过滤条件并不是越多越好。Query语句的性能优劣最关键的是要让它选择一条最佳的数据访问路径，做到访问最少的数据量完成自己的任务。

占用空间更大，代表访问该索引须要读取的数据量就会越多。

具体优化Query语句的指导原则——尽可能避免复杂的Join和子查询

Query语句所涉及的表越多，须要锁定的资源就越多。越复杂的Join语句，锁定的资源也就越多，所阻塞的其他线程也就越多。

如果将较复杂的Query语句分拆成多个较简单的Query语句分步执行，每次锁定的资源也就会少很多，所阻塞的其他线程也要少一些。

将复杂Join语句分拆成多个简单的Query语句之后，会增大网络交互。

一个复杂的Join Query语句在执行的时候，须要锁定的资源较多，被别人阻塞的概率也更大，如果是一个简单的Query，由于须要锁定的资源较少，被阻塞的概率也会小很多。所以，较为复杂的Join Query有可能在执行时被阻塞而浪费了更多的时间。数据库并不是只是服务某一个Query请求，还有很多其他的请求，在高并发的系统中，牺牲单个 Query的短暂响应时间而提高整体处理能力是非常值得的。返回搜狐，查看更多

责任编辑：