mysql text cpu_mysql 占CPU100%处理一则

今天下班前一位同事负责的一套mysql数据库的CPU使用率达到100%,登上服务器top查看

Cpu(s):  95.9%us,  4.0%sy,  0.0%ni, 0.0%id,  20.0%wa,  0.0%hi,  0.0%si,  0.0%st

由于一直是在做oracle的维护,对mysql不熟悉,先在网上查了几篇文章,但好像都是一个人写的,不过从这些文章中也有了一个大体的处理思路。(由于不是我本人操作,没有记录详细的日志,这里只介绍下处理过程和使用到的命令,正文中的代码只是后期为说明加的。)

先使用root用户登上mysql,使用 show processlist命令查看当前哪些线程正在运行。查看下来一共有160多个mysql> show processlist;

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

| Id | User | Host      | db   | Command | Time | State | Info             |

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

|  1 | root | localhost | NULL | Query   |    0 | init  | show processlist |

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

1 row in set (0.00 sec)

先简单说一下各列的含义和用途:

id    一个标识,你要kill一个语句的时候很有用。

user   显示当前用户,如果不是root,这个命令就只显示你权限范围内的sql句。

host   显示这个语句是从哪个ip 哪个端口上发出的。可以用来追踪出问题语句的用户。

db    显示这个进程目前连接的是哪个数据库。

command 显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。

time   此这个状态持续的时间,单位是秒。

state  显示使用当前连接的sql语句的状态,很重要的列。state只是语句执行中的某一个状态,以查询sql为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成。

info  显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。

从show processlist命令输出的结果看到有一条sql语句重复出现,但是info列显示的不全只有select a.col1,a.col2,a.col3 from table1 a这样的信息。那就先从这个表入手查,select count(*) from table1;查出这张表有60W+的数据。select count(*) 使用了6秒。但是现在不确定这个语句执行的时候有没有where条件。

继续查资料,查到show processlist命令出的结果出处information_schema库下的processlist表。mysql> use information_schema

Database changed

mysql> desc processlist;

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

| Field   | Type                | Null | Key | Default | Extra |

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

| ID      | bigint(21) unsigned | NO   |     | 0       |       |

| USER    | varchar(16)         | NO   |     |         |       |

| HOST    | varchar(64)         | NO   |     |         |       |

| DB      | varchar(64)         | YES  |     | NULL    |       |

| COMMAND | varchar(16)         | NO   |     |         |       |

| TIME    | int(7)              | NO   |     | 0       |       |

| STATE   | varchar(64)         | YES  |     | NULL    |       |

| INFO    | longtext            | YES  |     | NULL    |       |

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

8 rows in set (0.04 sec)

可看到表porcesslist表的列跟show processlist输出的列是一致的。

再查询processlist表时发现info信息是完整的,在这里找到上边怀疑的sql的完整版为select a.col1,a.col2,a.col3 from table1 a where a.col4='123' and a.col5='abc';

查看这个语句的执行计划(类似下面这种)mysql> explain select ename,hiredate,sal from emp where sal=1000 \G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: emp

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 3072

Extra: Using where

1 row in set (0.00 sec)

ERROR:

No query specified

可以看出语句没有使用索引而是使用全表扫描。分别对col4='123' 和col5='abc'做了统计,发现col4='123'的记录只有一条,而col5='abc'的记录有5W+条,很明显在col4上创建索引执行效率会高很多。查看表上是否有col4列上的索引(类似下面这种)。mysql> show index from emp \G;

*************************** 1. row ***************************

Table: emp

Non_unique: 1

Key_name: idx_emp_2

Seq_in_index: 1

Column_name: deptno

Collation: A

Cardinality: 6

Sub_part: NULL

Packed: NULL

Null: YES

Index_type: BTREE

Comment:

Index_comment:

1 row in set (0.00 sec)

ERROR:

No query specified

发现col4列上没有索引,表的存储引擎为 InnoDB,于是在col4列上创建索引mysql> show table status from test1 like 'emp'\G;

*************************** 1. row ***************************

Name: emp

Engine: InnoDB

Version: 10

Row_format: Compact

Rows: 3072

Avg_row_length: 53

Data_length: 163840

Max_data_length: 0

Index_length: 65536

Data_free: 0

Auto_increment: NULL

Create_time: 2016-11-15 21:54:49

Update_time: NULL

Check_time: NULL

Collation: gbk_chinese_ci

Checksum: NULL

Create_options:

Comment:

1 row in set (0.00 sec)

ERROR:

No query specified

mysql> create index idx_sal on emp(sal);

Query OK, 0 rows affected (0.15 sec)

Records: 0  Duplicates: 0  Warnings: 0

再次查看执行计划,发现语句使用索引扫描。mysql> explain select ename,hiredate,sal from emp where sal=1000 \G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: emp

type: ref

possible_keys: idx_sal

key: idx_sal

key_len: 6

ref: const

rows: 1

Extra: NULL

1 row in set (0.00 sec)

ERROR:

No query specified

sql语句的执行效率立马提升。CPU的使用率也降下来了。

这也还有一个疑问,oracle在创建索引时为了避免锁表引入了online创建索引。不知道mysql中如何在线创建索引?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目标检测(Object Detection)是计算机视觉领域的一个核心问题,其主要任务是找出图像中所有感兴趣的目标(物体),并确定它们的类别和位置。以下是对目标检测的详细阐述: 一、基本概念 目标检测的任务是解决“在哪里?是什么?”的问题,即定位出图像中目标的位置并识别出目标的类别。由于各类物体具有不同的外观、形状和姿态,加上成像时光照、遮挡等因素的干扰,目标检测一直是计算机视觉领域最具挑战性的任务之一。 二、核心问题 目标检测涉及以下几个核心问题: 分类问题:判断图像中的目标属于哪个类别。 定位问题:确定目标在图像中的具体位置。 大小问题:目标可能具有不同的大小。 形状问题:目标可能具有不同的形状。 三、算法分类 基于深度学习的目标检测算法主要分为两大类: Two-stage算法:先进行区域生成(Region Proposal),生成有可能包含待检物体的预选框(Region Proposal),再通过卷积神经网络进行样本分类。常见的Two-stage算法包括R-CNN、Fast R-CNN、Faster R-CNN等。 One-stage算法:不用生成区域提议,直接在网络中提取特征来预测物体分类和位置。常见的One-stage算法包括YOLO系列(YOLOv1、YOLOv2、YOLOv3、YOLOv4、YOLOv5等)、SSD和RetinaNet等。 四、算法原理 以YOLO系列为例,YOLO将目标检测视为回归问题,将输入图像一次性划分为多个区域,直接在输出层预测边界框和类别概率。YOLO采用卷积网络来提取特征,使用全连接层来得到预测值。其网络结构通常包含多个卷积层和全连接层,通过卷积层提取图像特征,通过全连接层输出预测结果。 五、应用领域 目标检测技术已经广泛应用于各个领域,为人们的生活带来了极大的便利。以下是一些主要的应用领域: 安全监控:在商场、银行
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值