【MySQL】查询优化实例解析-延迟关联优化

【提出问题】

从数据表t通过分页查询的方式读取数据，读取时要根据a1排序。t有80万行记录，当OFFSET很大时，读取速度很慢。优化后查询速度提升很快。

下图是表的定义，一共有几十个字段，RowLength大概500字节。除了主键，没有其他索引。

CREATE TABLE `t` (
  `a0` ) NOT NULL,
  `a1` ) NOT NULL,
  `a2` ,) NOT NULL DEFAULT '0.000000000',
  `a3` ,) NOT NULL DEFAULT '0.000000000',
  `a4` ,) NOT NULL DEFAULT '0.000000000',
  `a5` ,) NOT NULL DEFAULT '0.000000000',
  `a6` ,) NOT NULL DEFAULT '0.000000000',
  `a7` ,) NOT NULL DEFAULT '0.000000000',
  `a8` ,) NOT NULL DEFAULT '0.000000000',
  `a9` ,) NOT NULL DEFAULT '0.000000000',
  `b1` ,) NOT NULL DEFAULT '0.000000000',
  `b2` ,) NOT NULL DEFAULT '0.000000000',
  `b3` ,) NOT NULL DEFAULT '0.000000000',
  `b4` ,) NOT NULL DEFAULT '0.000000000',
  `b5` ,) NOT NULL DEFAULT '0.000000000',
  `b6` ,) NOT NULL DEFAULT '0.000000000',
  `b7` ,) NOT NULL DEFAULT '0.000000000',
  `b8` ,) NOT NULL DEFAULT '0.000000000',
  `b9` ,) NOT NULL DEFAULT '0.000000000',
  `c1` ,) NOT NULL DEFAULT '0.000000000',
  `c2` ,) NOT NULL DEFAULT '0.000000000',
  `c3` ,) NOT NULL DEFAULT '0.000000000',
  `c4` ,) NOT NULL DEFAULT '0.000000000',
  `c5` ,) NOT NULL DEFAULT '0.000000000',
  `c6` ,) NOT NULL DEFAULT '0.000000000',
  `c7` ) ',
  `c8` ) ',
  `c9` ) ',
  `d1` ) ',
  `d2` ) ',
  `d3` ,) NOT NULL DEFAULT '0.000000000',
  `d4` ,) NOT NULL DEFAULT '0.000000000',
  `d5` ,) NOT NULL DEFAULT '0.000000000',
  `d6` ,) NOT NULL DEFAULT '0.000000000',
  `d7` ,) NOT NULL DEFAULT '0.000000000',
  `d8` ,) NOT NULL DEFAULT '0.000000000',
  `d9` ) ',
  `e1` ,) NOT NULL DEFAULT '0.000000000',
  `e2` ,) NOT NULL DEFAULT '0.000000000',
  `e3` ,) NOT NULL DEFAULT '0.000000000',
  `e4` ,) NOT NULL DEFAULT '0.000000000',
  `e5` ,) NOT NULL DEFAULT '0.000000000',
  `e6` ,) NOT NULL DEFAULT '0.000000000',
  `e7` ,) NOT NULL DEFAULT '0.000000000',
  `e8` ,) NOT NULL DEFAULT '0.000000000',
  `e9` ,) NOT NULL DEFAULT '0.000000000',
  `f1` ,) NOT NULL DEFAULT '0.000000000',
  `f2` ,) NOT NULL DEFAULT '0.000000000',
  PRIMARY KEY (`a0`,`a1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

表基本信息

SELECT * FROM tables where table_name='t'\G
. row ***************************
  TABLE_CATALOG: def
   TABLE_SCHEMA: test
     TABLE_NAME: t
     TABLE_TYPE: BASE TABLE
         ENGINE: InnoDB
        VERSION:
     ROW_FORMAT: Compact
     TABLE_ROWS:
 AVG_ROW_LENGTH:
    DATA_LENGTH:
MAX_DATA_LENGTH:
   INDEX_LENGTH:
      DATA_FREE:
 AUTO_INCREMENT: NULL
    CREATE_TIME:  ::
    UPDATE_TIME: NULL
     CHECK_TIME: NULL
TABLE_COLLATION: utf8_general_ci
       CHECKSUM: NULL
 CREATE_OPTIONS:
  TABLE_COMMENT:

原始SQL

--SQL1--
,;
 row in SET (6.67 sec)

--SQL2--
,) AS A USING (a0, a1);
 row in set (0.90 sec)

 SQL2使用的是经典的延迟关联优化: 首先根据条件查出主键，再用INNER JOIN查出需要的数据集。

 

问题：为什么SQL2速度有这么大的提升呢？  

 

【背景知识】

1. 使用 Optimizer Trace 观察SQL执行过程（http://www.cnblogs.com/skylerjiang/p/mysql_optimizer_trace_intro.html）
2. MySQL排序内部原理探秘 （http://geek.csdn.net/news/detail/105891）

 

查看sort_buffer配置，打开Optimizer Trace

SHOW variables like '%sort%';
+--------------------------------+---------------------+
| Variable_name                  | Value               |
+--------------------------------+---------------------+
                |
             |
+--------------------------------+---------------------+
排序buffer为8M

SET optimizer_trace="enabled=on";
;
SELECT trace FROM information_schema.optimizer_trace\G

【问题分析】

SQL1执行过程

,; SELECT trace FROM information_schema.optimizer_trace\G

  

（右键新窗口打开查看完整图片）

解析

1. SELECT *， 读取数据的时候，需要读取所有的字段。
2. a1没有索引，将使用全表扫描。
3. priority_queue优化检查
   1. LIMIT 100000,1  需要排序TOP 100001行（再丢弃100000行，取1行）
   2. 每行454字节，100001行需要45,400,454字节，大于sort_buffer_size（8,388,608），数据集无法直接纳入buffer
   3. 尝试去除additionl_fields（数据字段），使用sortkey+rowid的方式，row_size=74，可以在buffer中存放
   4. 估算merge_sort和priority_queue_cost，前者比后者小，放弃使用priority_queue
4. sort_mode=<sort_key,additional_fields>，需要使用外部排序，分片数量46。

SQL2执行过程

,) AS A USING (a0, a1);
SELECT trace FROM information_schema.optimizer_trace\G

解析

1. 首先执行子查询 SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 100000,1
   1. 只需要读取a0和a1两个字段
   2. a1没有索引，将使用全表扫描。
   3. priority_queue优化检查
      1. LIMIT 100000,1  需要排序TOP 100001行（丢弃100000行，取1行）
      2. 每行66字节，100001行需要6,600,066字节，小于sort_buffer_size（8,388,608），数据集可以纳入buffer
      3. 使用priority_queue
   4. 执行完毕，结果存储在临时表A里面
2. 临时表A只有1行，连表查询时，可以使用 t 的主键，非常快速。

结论

1. 全表扫描时，SQL1需要读取所有字段（大约500字节），SQL2只需要读取2个字段（小于100字节）。
2. SQL1需要使用外部排序，分片数量又比较多（46个），所以比较慢。
3. SQL2数据可以存放在sort_buffer里面，还可以启用优先队列优化，加速明显。　　

【场景扩展】

1. Limit对执行过程的影响

 稍微修改下SQL语句，把 LIMIT 100000,1 修改为 LIMIT 600000,1，看看执行过程。

 

SQL1执行过程

,;
 row in set (8.82 sec)

SELECT trace FROM information_schema.optimizer_trace\G

这次的执行过程完全一样，但决策依据稍有不同。600001行数据，即使去除additional fields，也需要44,400,074字节，超过了8M的sort_buffer_size，not_enough_space，无法使用priority_queue。原来是因为priority_queue_cost>merge_sort_cost而放弃。

SQL2执行过程

,) AS A USING (a0, a1);
 row in set (1.05 sec)

SELECT trace FROM information_schema.optimizer_trace\G

执行过程有比较大改变：由于LIMIT太大，超过了sort_buffer，所以

• 无法启用优先队列优化，

使用了外部排序，共8个分片。

 

2. 不同sort_mode的影响

以上测试，都是additional_fields模式，如果是rowid模式，会怎么样呢？

;

SQL1执行过程

,;
 row in set (4.16 sec)

排序模式变成了rowid模式，速度变快了。这是因为排序时只需要读取排序字段和rowid，外部排序的分片数量减少了。

SQL2执行过程

,) AS A USING (a0, a1);
 row in set (1.05 sec)

执行模式没有改变，因为sizeof(a0+a1)<100，还是能用priority_queue优化。

【参考资料】

1. 使用 Optimizer Trace 观察SQL执行过程（http://www.cnblogs.com/skylerjiang/p/mysql_optimizer_trace_intro.html）
2. MySQL排序内部原理探秘 （http://geek.csdn.net/news/detail/105891）
3. filesort.cc 源代码阅读笔记 http://www.cnblogs.com/skylerjiang/p/6269310.html