mysql count null_一个不可思议的MySQL慢查分析与解决
点击上方蓝色字体,选择“标星公众号”
优质文章,第一时间送达
最近,开发人员需要定期的删除表里一定时间以前的数据,SQL如下:
mysql > delete from testtable WHERE biz_date <= '2017-08-21 00:00:00' AND status = 2 limit 500\G
前段时间在优化的时候,我们已经在相应的查询条件上加上了索引,如下:
KEY `idx_bizdate_st` (`biz_date`,`status`)
但是实际执行的SQL依然非常慢,为什么呢,我们来一步步分析验证下。
# 分析
表上的字段既然都有索引,那么按照之前的文章分析,是两个字段都可以走上索引的。
既然能够利用索引,表的总大小也就是200M左右,那么为什么形成了慢查呢?
我们查看执行计划,去掉limit 后,发现他选择了走全表扫描。
mysql > desc select * from testtable WHERE biz_date <= '2017-08-21 00:00:00';+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+| 1 | SIMPLE | testtable | ALL | idx_bizdate_st | NULL | NULL | NULL | 980626 | Using where |+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+1 row in set (0.00 sec)-- 只查询biz_date-- 关键点:rows:980626;type:ALLmysql > desc select * from testtable WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+| 1 | SIMPLE | testtable | ALL | idx_bizdate_st | NULL | NULL | NULL | 980632 | Using where |+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+1 row in set (0.00 sec)-- 查询biz_date + status -- 关键点:rows:980632;type:ALLmysql > desc select * from testtable WHERE biz_date <= '2017-08-21 00:00:00' and status = 2 limit 100;+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+| 1 | SIMPLE | testtable | range | idx_bizdate_st | idx_bizdate_st | 6 | NULL | 490319 | Using index condition |+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+1 row in set (0.00 sec)-- 查询biz_date + status+ limit -- 关键点:rows:490319;mysql > select count(*) from testtable WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;+----------+| count(*) |+----------+| 0 |+----------+1 row in set (0.34 sec)mysql > select count(*) from testtable WHERE biz_date <= '2017-08-21 00:00:00';+----------+| count(*) |+----------+| 970183 |+----------+1 row in set (0.33 sec)mysql > select count(*) from testtable;+----------+| count(*) |+----------+| 991421 |+----------+1 row in set (0.19 sec)mysql > select distinct biz_status from testtable;+------------+| biz_status |+------------+| 1 || 2 || 4 |+------------+
通过以上查询,我们可以发现如下几点问题:
通过 biz_date 预估出来的行数 和 biz_date + status=2 预估出来的行数几乎一样,为98w。
实际查询表 biz_date + status=2 一条记录都没有。
整表数据量达到了99万,MySQL发现通过索引扫描需要98w行(预估)
因此,MySQL通过统计信息预估的时候,发现需要扫描的索引行数几乎占到了整个表,放弃了使用索引,选择了走全表扫描。
那是不是他的统计信息有问题呢?我们重新收集了下表统计信息,发现执行计划的预估行数还是一样,猜测只能根据组合索引的第一个字段进行预估(待确定)。
那我们试下直接强制让他走索引呢?
mysql > select * from testtable WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;Empty set (0.79 sec)mysql > select * from testtable force index(idx_bizdate_st) WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;Empty set (0.16 sec)
我们发现,强制指定索引后,查询耗时和没有强制索引比较,的确执行速度快了很多,因为没有强制索引是全表扫描嘛!但是!依然非常慢!
那么还有什么办法去优化这个本来应该很快的查询呢?
大家应该都听说过要选择性好的字段放在组合索引的最前面?
选择性好的索引在前面并不是对所有的场景都通用的,这个场景可以将status放前面,sql速度会更快。
那,能不能让他不要扫描索引的那么多范围呢?之前的索引模型中也说过,MySQL是通过索引去确定一个扫描范围,如果能够定位到尽可能小的范围,那是不是速度上会快很多呢?
并且业务逻辑上是定期删除一定日期之前的数据。所以逻辑上来说,每次删除都是只删除一天的数据,直接让SQL扫描一天的范围。那么我们就可以改写SQL啦!
mysql > select * from testtable WHERE biz_date >= '2017-08-20 00:00:00' and biz_date <= '2017-08-21 00:00:00' and status = 2;Empty set (0.00 sec)mysql > desc select * from testtable WHERE biz_date >= '2017-08-20 00:00:00' and biz_date <= '2017-08-21 00:00:00' and status = 2;+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+| 1 | SIMPLE | testtable | range | idx_bizdate_st | idx_bizdate_st | 6 | NULL | 789 | Using index condition |+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+1 row in set (0.00 sec)-- rows降低了很多,乖乖的走了索引mysql > desc select * from testtable WHERE biz_date >= '2017-08-20 00:00:00' and biz_date <= '2017-08-21 00:00:00' ;+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+| 1 | SIMPLE | testtable | range | idx_bizdate_st | idx_bizdate_st | 5 | NULL | 1318 | Using index condition |+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+1 row in set (0.00 sec)-- 即使没有status,也是肯定走索引啦
# 小结
这个问题,我原本打算用hint,强制让他走索引,但是实际上强制走索引的执行时间并不能带来满意的效果。结合业务逻辑,来优化SQL,是最好的方式,也是终极法宝,一定要好好利用。不了解业务的DBA,不是一个好DBA...
-End-
喜欢文章,点个在看
mysql count null_一个不可思议的MySQL慢查分析与解决相关推荐
- 怎么抽象mysql数据库_一个用于mysql的数据库抽象层函数库
一个用于mysql的数据库抽象层函数库 更新时间:2006年10月09日 00:00:00 作者: // // SourceForge: Breaking Down the Barriers to ...
- java mysql proxy_Amoeba是一个类似MySQL Proxy的分布式数据库中间代理层软件,是由陈思儒开发的一个开源的java项目...
Amoeba(变形虫)项目是一个开源框架,于2008年开始发布一款 Amoeba for Mysql软件: 这个软件致力于MySQL的分布式数据库前端代理层,它主要在应用层访问MySQL的时候充当SQ ...
- MySQL数据库服务器逐渐变慢 该如何分析与解决
第一步 检查系统的状态 通过操作系统的一些工具检查系统的状态,比如CPU.内存.交换.磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲,这也可能不是一个正常的状态,因为cp ...
- MySQL server has gone away报错原因分析及解决办法
原因1. MySQL 服务宕了 判断是否属于这个原因的方法很简单,执行以下命令,查看mysql的运行时长 $ mysql -uroot -p -e "show global status l ...
- mysql 事务处理null_如何使用Mysql正确的处理财务数据
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼 财务数据相比于普通的互联网应用数据,对数据的一致性有更高的要求.因为涉及到用户金钱的流动,出现问题就意味金钱和声誉上的损失.在用 Mysql 处理财务数据 ...
- [MySQL]Software caused connection abort: recv failed 问题分析与解决
原文:http://blog.csdn.net/chuan122345/article/details/4894398 在项目开发时,遇到该异常,通过搜索在mysql官方网站上发现如下说明: I am ...
- 一个内核oops问题的分析及解决
个人简介 lccz(龙城赤子),资深嵌入式开发者,爱好Linux内核相关技术.个人CSDN博客:wwwyue1985. 最近在调试设备时,遇到了一个偶发的开机死机问题.通过查看输出日志,发现内核报告了 ...
- 一个内核 Oops 问题的分析及解决
说了这么多,那么到底是不是呢,验证一下就知道了.关闭上述选项,重新编译内核,之后再编译exfat,查看汇编,发现偏移回到了776.Yes,问题就是这里了. 最近在调试设备时,遇到了一个偶发的开机死机问 ...
- MySQL抓包工具:MySQL Sniffer
简介 MySQL Sniffer 是一个基于 MySQL 协议的抓包工具,实时抓取 MySQLServer 端的请求,并格式化输出.输出内容包访问括时间.访问用户.来源 IP.访问 Database. ...
最新文章
- java随机产生字母排序_Java生成含字母和数字的6位随机字符串
- NLP中的词向量及其应用
- HIGHGUI ERROR: V4L2: Pixel format of incoming image is unsupported by OpenCV
- 014_Collections常用方法
- 大学慕课数据结构单元测试——华中科技大学
- Multiple substitutions specified in non-positional format; did you mean to add the fo
- 技术圈儿002---高并发整体可用性:一文详解降级、限流和熔断
- Python自动化测试的学习笔记
- LeetCode简单题目(#53 #58 #66 #67 #69 #70 #83 #88)-8道
- Hdoj 1065题解
- 微机原理-80386(1)
- 加不了buff的BuffX,还能让年轻人买单多久?
- Sping Cloud专栏:路由Gateway有效避免 Only one connection receive subscriber allowed问题
- 基于Myrocks和spider构建分布式数据库
- EDA之立创EDA专业版使用(原理图绘制)
- 基于Modbus RTU 485通信协议实现对PH、溶解氧传感器的数据采集
- 原链YCC战略定位:公链+私链(联盟链、私有链),实现价值传递
- 51单片机汇编学习例程(9)——ADC0809篇
- matlab数据处理之批量解方程
- JAVA养老院管理系统计算机毕业设计Mybatis+系统+数据库+调试部署
热门文章
- CSS3 transform-style 属性
- 【leetcode】First Missing Positive(hard) ☆
- oc基础 不可变字符串的创建和使用
- MFC框架类、文档类、视图类相互访问的方法
- 求树中某结点的父结点(长子-兄弟表示法)
- Windows Phone 7 不温不火学习之《Expression Blend 创建渐变效果和创建Storyboard动画》...
- c++ time.h 用法
- 如何在 Linux 终端中复制粘贴 [初学者教程]
- Abseil之Copies, Abbrv
- 威纶通宏开机后使用初始化宏指令_你按下电脑开机键后,电脑都干了些什么?...