MySQL优化:order by和limit

1. 对order by使用复合索引

order by和limit一起使用,避免引起全表扫描和数据排序是非常重要的,因此借助合适的索引提高查询效率。

  • 使用联合索引
    联合索引又叫复合索引,是由表中的几个列联合组成的索引。联合索引生效需满足最左前缀原则,即如果联合索引列为a,b,c三列,a,b,c 、a,b 、a生效,b,c、a,c、b、c等不生效(此处的顺序不是where条件后面的先后顺序,而是where条件中是否存在这些列,如果where中只存在a,c列,则不生效)。

索引生效,与where条件的顺序无关:
select * from table where a= 'a' and c='c' and b='b';

索引失效,与where条件的列是否存在有关:
select * from table where b='b' and 'c'

> select * from product where model = 'abc' order by code desc limit 100;
索引分析:
product表已存在mode和code两个单索引,MySQL引擎只会选择其中一个区分度高的索引查询,所以使用的是code的索引,model索引没用上,导致查询效率变慢。
借助联合索引(model, code)可以显著提高查询效率。
  • 带IN条件的联合索引失效

联合索引生效:
select * from product where model in ('abc') order by code desc limit 100;

联合索引失效:
select * from product where model in ('abc', 'def') order by code desc limit 100;

联合索引生效:
select * from product force index(model_code) where model in ('abc', 'def') order by code desc limit 100;

in的参数个数为1个,联合索引生效,大于1个,索引失效。所以使用了强制索引使联合索引生效。
原因分析:
第一、取决于B树的数据结构,单参数的IN只会得到一颗基于model子树,该子树的code本身是有序的,所以索引生效,查询效率高;多参数的IN会得到多颗基于model的子树,每颗子树的code字段是有序的,但是总体上可能不是有序的,所以索引失效,查询效率低。
第二、使用强制索引后,理论上无法保证order by的顺序,但是如果数据本身的特性,比如时间递增的这类数据,总体上还是有序的,笔者试过多中途径想要迫使强制索引得到错误的结果,结果都对了。强制索引需进一步研究。

2. 大数据量limit慎用

  • limit常用于分页中,有两种用法,三种写法:
> SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset;

第一种写法,limit rows,如limit 10,返回从第1~10行,这种写法默认偏移量offset是0。
第二种写法,limit offset, rows,如limit 100, 10,返回第101~110行,第一个参数时偏移量offset,第二个参数时最大记录个数。
第三种写法,LIMIT rows OFFSET offset,如limit 10 offset 100,同第二种都是两个参数,形式不同。通常采用第一种或第二种写法。
  • 偏移量offset较大的优化
    limit偏移量较小时性能优秀,分页越到后面,偏移量递增,limit的性能会逐渐下降。
> select * from product limit 100;                             //cost time: 0.33s
> select * from product limit 10000, 100;                 //cost time: 0.37s
> select * from product limit 100000, 100;               //cost time: 0.61s
> select * from product limit 1000000, 100;             //cost time: 2.55s
> select * from product limit 10000000, 100;           //cost time: 20.41s

此时,通过子查询优化limit,效果如下:

> SELECT * FROM product WHERE ID >=(SELECT ID FROM product ORDER BY id LIMIT 100,1) LIMIT 100;                 //cost time: 0.37s
> SELECT * FROM product WHERE ID >=(SELECT ID FROM product ORDER BY id LIMIT 10000,1) LIMIT 100;                 //cost time: 0.34s
> SELECT * FROM product WHERE ID >=(SELECT ID FROM product ORDER BY id LIMIT 100000,1) LIMIT 100;                 //cost time: 0.46s
> SELECT * FROM product WHERE ID >=(SELECT ID FROM product ORDER BY id LIMIT 1000000,1) LIMIT 100;                 //cost time: 0.89s
> SELECT * FROM product WHERE ID >=(SELECT ID FROM product ORDER BY id LIMIT 10000000,1) LIMIT 100;                 //cost time: 4.73s

以上数据来自一张超过2000万的MySQL单表,仅供参考,能够说明子查询明显能够提升效率,笔者开始尝试把子查询的order by去掉,发现查询效率又提升2倍,但是对比发现数据不正确,explain后发现查询优化器给出的子查询索引并不是id(此表建有多个索引,id是主键,区分度最高),这一点比较困惑。

ps:在sql语句中,limt关键字是最后才用到的。以下条件的出现顺序一般是:where->group by->having-order by->limit

你可能感兴趣的:(MySQL优化:order by和limit)