12月25日，在查看某客户监控时，发现了客户执行了超过60s的分页查询，执行情况如下：
这是一个很简单、典型的分页查询SQL，khome_space.regdate列上有索引，表有三百多万行数据。而查询的偏移量太大，所以导致分页查询过于耗时。随后在自己的本地环境模拟了下这个场景，以我自己本地100万数据行的t_operater_record表为例，来优化一下查询。
模拟出客户的分页查询操作，查看对应的执行计划：
mysql> explain
-> select t.id,t.operationer,t.operater_method,t.operater_param,t.num,t.updated_time
-> from t_operater_record t
-> order by t.updated_time desc
-> limit 950000,50;
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+
| 1 | SIMPLE | t | NULL | ALL | NULL | NULL | NULL | NULL | 996580 | 100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+客户的regdate列有索引，我的updated_time列也有索引。通过执行计划来看，确实不太理想，本地执行这个SQL耗时6.79s。
对SQL进行改写，优化后SQL的执行计划：
mysql> explain
-> SELECT t.id,t.operationer,t.operater_method,t.operater_param,t.num,t.updated_time
-> FROM t_operater_record t
-> JOIN ( SELECT id
-> FROM `t_operater_record`
-> ORDER BY updated_time DESC
-> limit 950000,50) a on t.id=a.id;
+----+-------------+-------------------+------------+--------+---------------+----------------+---------+------+--------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------------------+------------+--------+---------------+----------------+---------+------+--------+----------+-------------+
| 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 950050 | 100.00 | NULL |
| 1 | PRIMARY | t | NULL | eq_ref | PRIMARY | PRIMARY | 8 | a.id | 1 | 100.00 | NULL |
| 2 | DERIVED | t_operater_record | NULL | index | NULL | i_updated_time | 5 | NULL | 950050 | 100.00 | Using index |
+----+-------------+-------------------+------------+--------+---------------+----------------+---------+------+--------+----------+-------------+执行计划实际上是很优的。虽然从执行计划来看，子查询a这一步的rows值为950050，但是extra显示using index，表示这一步只访问了索引i_updated_time，没有回表操作，而扫描索引的操作是很快的；之后再以子查询返回的结果集为驱动表，与原表关联取完整数据。
这个SQL执行时间0.38s，执行时间大大提升。
