MySQL 深度分页优化

理解总结：

分页使用limit ，前提是要排序好的数据，这时候，就推荐使用带索引的字段排序，因为索引是天然有序的，不需要像是无序的字段一样，全表扫描，如果太大的话，还filesort ，利用文件排序，排序完成之后，才能分页，很慢。但是，如果分页过深的话，比如limit100万，仍然无需要查询到100万数据，中间有大量的io操作（回表查询其它字段），这时候考虑用上子查询，先查到100万位置的往后10条数据（直接用id主键查，因为没有回表，直接索引查，所以很快），然后再关联10条数据，取得完整的数据。

举例：

1. 没有查询条件，没有排序

耗时0.613s

select id,m_id, name, identity_no, address, create_time, modify_time  from t1 limit 1000000, 20;

加上主键排序

耗时0.41

**select** id,m_id, name, identity_no, address, create_time, modify_time  **from** t1 **order** **by** id limit 1000000, 20;

加上主键排序，使用了主键索引，天然有序，所以只读取前n条数据，所以更快。

2. 带排序-排序字段没有索引

select id,m_id, name, identity_no, address, create_time, modify_time 
from t1 
order by create_time desc 
limit 10000, 20;

耗时2秒左右

select id,m_id, name, identity_no, address, create_time, modify_time
from t2
order by create_time desc
limit 10000, 20;

与t1基本相同，只是加了索引，耗时0.9s左右

对比：没有索引的表，全表扫描，排序用到filesort 。有索引的话，可以利用索引排序，limit 的话，扫描的数据有少。

3. 排序字段有索引，但是分页很深，从100w开始取20条。

select id,m_id, name, identity_no, address, create_time, modify_time 
from t2 
order by create_time desc 
limit 1000000, 20;

很慢，没有走索引，因为MySQL优化器发现这条sql查询超过一定的比例，就会自动转成全表扫描。

加force index(idx)，强制走索引。有效果，但是不明显。

结论：即使有索引，再深一点的分页也会有问题，要避免

5. 解决方案

联表子查询

-- 改为：
SELECT   id, m_id, NAME, identity_no, address, create_time, modify_time 
FROM t2
JOIN ( SELECT id FROM t2 ORDER BY create_time desc LIMIT 1000000, 20 ) x USING ( id );

变成0.7s；原来15s。

-- 在t1执行：
SELECT   id, m_id, NAME, identity_no, address, create_time, modify_time 
FROM t1
JOIN ( SELECT id FROM t1 ORDER BY create_time desc LIMIT 1000000, 20 ) x USING ( id );