本篇内容介绍了“如何理解MySQL limit导致的执行计划差异”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
今天收到一个业务的报警，提示慢日志比较频繁，登上环境查看，发现SQL是一条看起来很简单的语句，环境在MySQL 5.7.16版本下，慢日志里面执行时间显示是近1分钟，我在从库上面执行了一下，发现优化空间确实很大：
select OrgId from `testcomm`.apply_join_org where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc LIMIT 1; Empty set (48.71 sec)
执行计划如下:
explain select OrgId -> from `testcomm`.apply_join_org -> where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc LIMIT 1\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: apply_join_org partitions: NULL type: index possible_keys: IndexRTUser key: IndexCreateTime key_len: 5 ref: NULL rows: 4332 filtered: 0.00 Extra: Using where 1 row in set, 1 warning (0.00 sec)
到了这个时候，不上表结构有些草率了，结构有所删减。
CREATE TABLE `apply_join_org` ( `ApplyJoinId` int(11) NOT NULL AUTO_INCREMENT, `RTId` int(11) DEFAULT NULL, `UserId` int(11) NOT NULL, `OrgId` int(11) NOT NULL, `ApplyMsg` varchar(100) DEFAULT NULL, `CreateTime` datetime NOT NULL, `ReplyMemId` int(11) DEFAULT '0', `ReplyTime` datetime NOT NULL, `ApplyStatus` tinyint(4) DEFAULT '1' COMMENT '0拒绝1申请2同意', `IfDel` tinyint(4) DEFAULT '1', `UpdateTime` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `RP` int(11) DEFAULT '0' COMMENT 'RP值', `sex` tinyint(1) DEFAULT NULL, `IfLeaguer` tinyint(1) NOT NULL DEFAULT '0', PRIMARY KEY (`ApplyJoinId`), KEY `IndexOrgIdStatus` (`OrgId`,`ApplyStatus`,`IfDel`), KEY `IndexRTUser` (`UserId`), KEY `IndexCreateTime` (`CreateTime`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=22495957 DEFAULT CHARSET=utf8 1 row in set (0.00 sec)
此外涉及的这张表的数据量有2000万左右，从目前的执行效率来看，无疑于走了一个全表扫描。
其实这个问题到了这个还是比较好理解的。从语句的表现，结合表结构，我们可以感觉到： 整个SQL的执行过程中，原本是基于字段UserId，没想到却因为order by中的CreateTime，导致索引选择错误，执行代价差异很大。
所以到了这里，我们如何来定性这个问题：
1)是因为order by导致的吗?
2)是因为时间字段的排序导致的吗?
3)是因为limit操作导致的吗?
4)是因为userid本身的数据过滤效果差导致的吗?null
