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 1G
*************************** 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本身的数据过滤效果差导致的吗?
对于这些疑问,我们可以很快通过几条对比SQL就能够快速验证。
通过如下的SQL可以看到order by不是最主要的原因
select OrgId
-> from `testcomm`.apply_join_org
-> where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime ;
Empty set (0.01 sec
order by排序也不是最主要的原因
select OrgId
-> from `testcomm`.apply_join_org
-> where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc ;
Empty set (0.01 sec)
order by排序+limit 10也不是最主要的原因
select OrgId
from `testcomm`.apply_join_org
where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc LIMIT 10;
Empty set (0.01 sec)
order by 排序+limit 2也不是最主要的原因
select OrgId
-> from `testcomm`.apply_join_org
-> where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc LIMIT 2;
Empty set (0.01 sec)
而经过这些对比,主要加入了limit 1,索引选择情况就会发生变化。我们抓取一条limit 2的执行计划来看看。可以明显看到type为ref,此外ref部分差异很大(const)。
>explain select OrgId from `testcomm`.apply_join_org where IfDel=1 and ApplyStatus=1 and UserId = 12345678 ORDER BY CreateTime desc LIMIT 2G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: apply_join_org
partitions: NULL
type: ref
possible_keys: IndexRTUser
key: IndexRTUser
key_len: 4
ref: const
rows: 4854
filtered: 1.00
Extra: Using index condition; Using where; Using filesort
1 row in set, 1 warning (0.00 sec)
如果想得到更进一步的信息,可以使用如下的方式:
SET optimizer_trace="enabled=on"
SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACEG
查看
reconsidering_access_paths_for_index_ordering部分的信息会是关键所在。
"index_provides_order": true,
"order_direction": "desc",
而对于这个问题的分析,主要还是在于对于cost的评估方式,显然在目前的测试中,增加了额外的order by排序操作,导致了代价会略微高一些,而在优化器中在评估中,显然这部分是缺失了一些信息导致判断失误。
有如下几种方式可以修复:
1)补充完整的复合索引,userid和CreateTime能够做到互补,该方案已经在同构环境中做了完整的模拟测试,能够达到预期
alter table `testcomm`.apply_join_org drop key IndexRTUser;
alter table `testcomm`.apply_join_org add key `IndexRTUser2`(UserId,CreateTime);
2)使用force index的hint方式来强制索引,当然对于业务具有一定的侵入性
3)调整SQL逻辑模式,确实是否可以使用其他的方式来代替这种limit 1的使用模式。
而从长计议,其实整个评估中的优化器还是比较薄弱的,对于索引选择中的判断依据,如果有了直方图等辅助信息,整个过程会更加如虎添翼,这块的内容,准备在8.0中进行一些模拟测试,稍后奉上测试结果。
- JavaScript 背包问题详解
- 【干货】用于机器学习的线性代数速查表
- 使用机器学习预测天气(第一部分)
- linux 常用指令
- LCS 算法:Javascript 最长公共子序列
- 短网址(short URL)系统的原理及其实现
- 设计和实现一款轻量级的爬虫框架
- JavaScript实现模糊推荐的input框(类似搜索框)
- hadoop streaming编程小demo(python版)
- 一个scrapy框架的爬虫(爬取京东图书)
- mongodb生产环境(副本集模式)集群搭建配置
- ELK日志收集分析系统配置
- 【学术】如何在15分钟内建立一个深度学习模型?
- Elasticsearch(GEO)空间检索查询
- MySQL 教程
- MySQL 安装
- MySQL 管理与配置
- MySQL PHP 语法
- MySQL 连接
- MySQL 创建数据库
- MySQL 删除数据库
- MySQL 选择数据库
- MySQL 数据类型
- MySQL 创建数据表
- MySQL 删除数据表
- MySQL 插入数据
- MySQL 查询数据
- MySQL where 子句
- MySQL UPDATE 查询
- MySQL DELETE 语句
- MySQL LIKE 子句
- mysql order by
- Mysql Join的使用
- MySQL NULL 值处理
- MySQL 正则表达式
- MySQL 事务
- MySQL ALTER命令
- MySQL 索引
- MySQL 临时表
- MySQL 复制表
- 查看MySQL 元数据
- MySQL 序列 AUTO_INCREMENT
- MySQL 处理重复数据
- MySQL 及 SQL 注入
- MySQL 导出数据
- MySQL 导入数据
- MYSQL 函数大全
- MySQL Group By 实例讲解
- MySQL Max()函数实例讲解
- mysql count函数实例
- MYSQL UNION和UNION ALL实例
- MySQL IN 用法
- MySQL between and 实例讲解
- 在keras中实现查看其训练loss值
- keras实现VGG16方式(预测一张图片)
- 利用python中的matplotlib打印混淆矩阵实例
- pytorch加载自己的图像数据集实例
- python实现批量转换图片为黑白
- Keras构建神经网络踩坑(解决model.predict预测值全为0.0的问题)
- Python实现验证码识别
- 详解PHP神奇又有用的Trait
- laravel实现按时间日期进行分组统计方法示例
- Pytorch 使用CNN图像分类的实现
- PHP实现无限极分类的两种方式示例【递归和引用方式】
- 记录模型训练时loss值的变化情况
- phpstorm 配置xdebug的示例代码
- 利用Python实现Excel的文件间的数据匹配功能
- PHP设计模式之简单工厂和工厂模式实例分析