优化步骤 2：记录上次返回的主键，在下次查询时使用主键过滤

SELECT film id, description FROM sakila.film WHERE film id >55 and film id <= 60 ORDER BY film id LIMIT 1, 5;

*避免了数据量大时扫描过多的记录

优化步骤 1：使用有索引的列或主键进行 Order by 操作

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

limit 常用于分页处理，时常会伴随 order by 从句使用，因此大多时候会使用 Filesorts 这样会造成大量的 IO 问题。

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

limit查询本身大量伴随order by处理，因此常常会是用filesort，因此造成大量io问题。

使用limit语句时，要考虑io问题可否进一步优化。

1：44显示，order by 操作中使用了表扫描的操作（type：all），产生大量io问题。（尽量用少的读写实现问题的解决）

优化方法步骤：

1.使用有索引的列或者逐渐进行order by 操作；（优化前是order by title非主键，优化后是order by film_id,是主键）；

2.偏移量(翻页的扫描数据量会随着偏移量增加而增加)优化：记录上次返回的主键，在下次查询时使用主键过滤（where 主键从句）；如：

偏移量是55，一页是5行数据， where film_id>55 and film_id<=60，则限定了从第56行查起，查到60行为止，从而大大降低了数据的扫描io操作；

这样直接可以避免扫描过多的记录。

其实也是在了解了limit执行方式之后，在不违反limit语句后台执行方式的逻辑下，对limit的操作进行了sql语句的限制，从而优化limit的io性能。

优化limit查询

使用有索引的列或主键进行order by操作

limit 优化:

limit会使用Filesorts这样造成大量的IO问题;

例如:select  film_id , description from salika.film order by title limit 500,5;

分析:当limit 后面的数据越大,IO越高,性能越差;可以使用主键排序进行优化,避免过多的扫描;

优化:select film_id , description from sakila.film where film_id >=500 and film_id <= 505 order by film_id limit 1,5;

这样每次秒扫描都只有5行  ,有个问题是:每个film_id索引列必须是连续的  ,如果不连续可能会导致查出来的列不足5行,解决方法:可以加一个索引列,保证是连续的,对该列查询;

优化limit查询

优化Limit查询

limit常用于分页处理，时常会伴随order by从句使用，因此大多时候会使用Filesorts这样会造成大量的io问题

1.使用有索引的列或主键进行order by操作

2.记录上次返回的主键，在下次查询时使用主键过滤

即将：select film_id,description from sakila.film order by film_id limit 50,5;

改为：select film_id,description from sakila.film where file_id >55 and film_id<=60 order by film_id limit 1,5;

使用这种方式有一个限制，就是主键一定要顺序排序和连续的，如果主键出现空缺可能会导致最终页面上显示的列表不足5条，解决办法是附加一列，保证这一列是自增的并增加索引就可以了

LIMIT优化