浅谈5.7limit优化

我从远处眺望你，仿佛你消失了一样。--至那些年你以为可以用到，却消失的索引。

 

夜已深，点支烟来记录下今天遇到的问题。

表结构如下所示：

 

pay_flow | CREATE TABLE `pay_flow` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `uuid` varchar(36) NOT NULL ,

  `flow_type` tinyint(4) NOT NULL ,

  `amount` varchar(20) NOT NULL ,

  `create_time` timestamp NOT NULL ,

  `operation_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',

  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',

  `pay_id` varchar(36) NOT NULL COMMENT '支付系统的唯一ID',

  `flow_status` tinyint(4) NOT NULL ,

  `user_uuid` varchar(36) DEFAULT NULL COMMENT '用户ID',

  `tf_uuid` varchar(20) NOT NULL DEFAULT ' ' COMMENT '交易明细ID',

  `ti_uuid` varchar(20) NOT NULL DEFAULT ' ' COMMENT '还款明细ID',

  `pay_status` tinyint(4) DEFAULT NULL COMMENT '1:成功，2:失败，3:需要支付，4:进行中',

  `original_tf_uuid` varchar(35) NOT NULL DEFAULT '0' COMMENT '原始的链条ID',

  PRIMARY KEY (`id`),

  UNIQUE KEY `index_user_payid_status` (`user_uuid`,`pay_id`,`flow_status`),

  KEY `pay_id` (`pay_id`),

  KEY `create_time` (`create_time`),

  KEY `index_original_tf_uuid` (`original_tf_uuid`),

  KEY `idx_uuid` (`uuid`)

) ENGINE=InnoDB AUTO_INCREMENT=154098216

 

sql如下：

 SELECT * FROM `pay_flow`  WHERE user_uuid='511933977553843466' ORDER BY `create_time` DESC LIMIT 50;

 

 

 

5.6.23版本的查询计划如下：

 

mysql> explain SELECT * FROM `pay_flow`  WHERE user_uuid='511933977553843466' ORDER BY `create_time` DESC LIMIT 50;

+----+-------------+----------+-------+-------------------------+-------------+---------+------+-------+-------------+

| id | select_type | table    | type  | possible_keys           | key         | key_len | ref  | rows  | Extra       |

+----+-------------+----------+-------+-------------------------+-------------+---------+------+-------+-------------+

|  1 | SIMPLE      | pay_flow | index | index_user_payid_status | create_time | 4       | NULL | 54309 | Using where |

+----+-------------+----------+-------+-------------------------+-------------+---------+------+-------+-------------+

1 row in set (0.00 sec)

 

抛开查询计划，闭着眼都知道，就当前的表结构而言，走user_uuid列的索引，会使得查询更快，mysql只需沿着索引列向下寻找大概不到30次就能完全找到所需要的uuid结果，然后会回表取出所有数据，根据create_time列排序，取前50，便可以得到最终想要的结果。然后根据5.6的查询计划，可能要花费2的N次方的时间才可以了。

然而，当我们舍弃limit后，5.6又会呈现出另外一种查询计划出来。

 

 

 

mysql> explain SELECT * FROM `pay_flow`  WHERE user_uuid='511933977553843466' ORDER BY `create_time` DESC;

+----+-------------+----------+------+-------------------------+-------------------------+---------+-------+-------+----------------------------------------------------+

| id | select_type | table    | type | possible_keys           | key                     | key_len | ref   | rows  | Extra                                              |

+----+-------------+----------+------+-------------------------+-------------------------+---------+-------+-------+----------------------------------------------------+

|  1 | SIMPLE      | pay_flow | ref  | index_user_payid_status | index_user_payid_status | 111     | const | 57072 | Using index condition; Using where; Using filesort |

+----+-------------+----------+------+-------------------------+-------------------------+---------+-------+-------+----------------------------------------------------+

1 row in set (0.00 sec)

 

 

 

终于正常的如我们想象的那样，不明白的是，为什么当遇到limit之后，mysql就糊涂了呢。我读书少，别骗我。

正常的查询，来看5.7的表现：

5.7貌似聪明了不少。明天再看结果吧。