Mysql分页&关联查询优化

如下内容参考《高性能Mysql》

优化关联查询

这个话题基本上整本书都在讨论，这里须要特别提到的是：

• 确保ON或者USING子句中的列上有索引。在建立索引的时候就要考虑到关联的顺序。
  当表A和表B用列c关联的时候，若是优化器的关联顺序是B、A，那么就不须要在B表的对应列上建上索引。没有用到的索引只会带来额外的负担。通常来讲，除非有其余理由，不然只须要在关联顺序中的第二个表的相应列上建立索引。

• 确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列，这样MySQL
  才有可能使用索引来优化这个过程。

• 当升级MySQL的时候须要注意：关联语法、运算符优先级等其余可能会发生变化
  的地方。由于之前是普通关联的地方可能会变成笛卡儿积，不一样类型的关联可能会生成不一样的结果

优化LIMIT分页

在系统中须要进行分页操做的时候，咱们一般会使用LIMIT加上偏移量的办法实现，同
时加上合适的ORDER BY子句。若是有对应的索引，一般效率会不错，不然，MySQL需
要作大量的文件排序操做。

一个很是常见又使人头疼的问题就是，在偏移量很是大的时候注”，例如多是LIMIT
1000,20这样的查询，这时MySQL须要查询1 0 020条记录而后只返回最后20条，前面
10 000条记录都将被抛弃，这样的代价很是高。若是全部的页面被访问的频率都相同，
那么这样的查询平均须要访问半个表的数据。要优化这种查询，要么是在页面中限制分
页的数量，要么是优化大偏移量的性能。

优化此类分页查询的一个最简单的办法就是尽量地使用索引覆盖扫描，而不是查询所
有的列。而后根据须要作一次关联操做再返回所需的列。对于偏移量很大的时候，这样
作的效率会提高很是大。考虑下面的查询：

mysql> SELECT film_id,description FROM sakila.film ORDER BY title LIMIT 50,5;

若是这个表很是大，那么这个查询最好改写成下面的样子：

mysql> SELECT film.film_id,Film.description
    ->  FROM  sakila.film
    ->INNER JOIN(
    ->  SELECT film.film_id FROM sakila.film
    ->  ORDER BY title LIMIT 50,5
    ->) AS lim USING(film_id);

这里的“延迟关联”将大大提高查询效率，它让MySQL扫描尽量少的页面，获取需
要访问的记录后再根据关联列回原表查询须要的全部列。这个技术也能够用于优化关联
查询中的LIMIT子句。

有时候也能够将LIMIT查询转换为已知位置的查询，让MySQL经过范围扫描得到到对
应的结果。例如，若是在一个位置列上有索引，而且预先计算出了边界值，上面的查询
就能够改写为：

mysql> SELECT film_id, description FROM sakila.Film
       -> WHERE position BETWEEN so AND 54 0RDER BY position;

对数据进行排名的问题也与此相似，但每每还会同时和GROUP BY混合使用。在这种状况
下一般都须要预先计算并存储排名信息。

LIMIT和OFFST的问题，实际上是OFFSET的问题．它会致使MySQL扫描大量不须要的
行而后再抛弃掉。若是可使用书签记录上次取数据的位置，那么下次就能够直接从该
书签记录的位置开始扫描，这样就能够避免使用OFFSET。例如，若须要按照租借记录作
翻页，那么能够根据最新一条租借记录向后追溯，这种作法可行是由于租借记录的主键
是单调增加的。首先使用下面的查询得到第一组结果：

mysql> SELECT * FROM sakila.rental
      -> ORDER BY rental id DESC LIMIT 20;

假设上面的查询返回的是主键为1 6 049到1 6 03 0的租借记录，那么下一页查询就能够
从1 6 030这个点开始：

mysql> SELECT * FROM sakila*rental
    -> WHERE rental id < 16030,
    -> ORDER BY rental id DESC LIMIT 20;

该技术的好处是不管翻页到多么后面，其性能都会很好。其余优化办法还包括使用预先计算的汇总表，或者关联到一个冗余表，冗余表只包含主键列和须要作排序的数据列。还可使用Sphinx优化一些搜索操做，参考附录F能够获得更多相关信息。