码迷,mamicode.com
首页 > 数据库 > 详细

Mysql监控调优

时间:2019-01-15 00:42:50      阅读:186      评论:0      收藏:0      [点我收藏+]

标签:5.6   资源   引入   value   删除表   连接池   nerd   链接   现在   

关系型数据库概念,有啥?

非关系型数据库概念,有啥?

 

要对表操作,是有权限控制的,我们自动会忽略这个权限问题

查询走硬盘的话,硬盘会影响性能。ssd>hdd

 

存储引擎:innerdb

 

首先,让我们来看一下SQL语句执行的过程,下面这个是我们平时写的SQL语句。

SELECT DISTINCT
    < select_list >
FROM
    < left_table > < join_type >
JOIN < right_table > ON < join_condition >
WHERE
    < where_condition >
GROUP BY
    < group_by_list >
HAVING
    < having_condition >
ORDER BY
    < order_by_condition >
LIMIT < limit_number >

 

然而当数据库接收到查询请求以后会先对数据进行解析,解析后查询顺序就变成了下面这样

 

FROM <left_table>
ON <join_condition>
<join_type> JOIN <right_table>
WHERE <where_condition>
GROUP BY <group_by_list>
HAVING <having_condition>
SELECT 
DISTINCT <select_list>
ORDER BY <order_by_condition>
LIMIT <limit_number>

 

sql语法的顺序:

1、from……where之间,是取表,取库,去磁盘里面把数据加载到内存里面,也就是磁盘的io会影响性能,读磁盘操作(整表全部放内存)

2、where,group by,having之后是条件,where实现的是筛选功能。这一步是在哪操作的?是在内存里面操作的(分组占用 cpu 特别高),这里对 cpu 的性能影响很大

  假设 where 之后筛选出 1W 数据,在 group by 后剩下 3000 ,having 后剩 1000 数据

3、order by 也是很耗费 cpu 的,排序算法,肯定很耗费 cpu

可以看到整个逻辑:取数据,选数据,排数据(取选排)伴随着的性能问题:io,内存和 cpu

 

抢 cpu 是怎么造成的?

进程都在占用 cpu ,突然一个 A 进程抢 cpu 暴增,那么其他的也会抢。比如说 a 进程要 10 m内存,内存 1%,那么没干完,被其他的抢走了,就会再要内存,内存就变成 2%,就这么其他的抢占也会一点一点增起来。一个高,另外的也会高,互相神仙打架。死的最多的是 tomcat ,java进程

 

DDL (Data Definition Language 数据定义语言)

技术分享图片
create table 创建表     
alter table  修改表   
drop table 删除表   
truncate table 删除表中所有行(把自增id清零)     
create index 创建索引   
drop index  删除索引
技术分享图片

 

DML (Data Manipulation Language 数据操作语言)

insert 将记录插入到数据库 
update 修改数据库的记录 
delete 删除数据库的记录

 

4、Mysql连接数

线程的连接数,比如 A 用户连一个, B用户连一个。

这里有个三次握手的概念,比如说客户端a问服务端b,我能打你么?b说,可以。那么a就去打b了,在他们没有说再见的状况下,b是一直等待被a打的,不会等其他的人来打

比如说我连上了 一个 mysql ,我不告诉 mysql 断开。是不会断开的,在我们一定的连接时间内(时间可配置)假设 30s,30s 内及时没有数据操作,这个数据库连接就是被占用的。影响:如果用户访问多,我们的连接数满了,其他的用户就连不上了。

那么我们引入连接池连接的方法。连接池,比如说最大连接数 100个,我设连接池 50 个,我设置的 50 为啥不设为 100 呢?为啥只设置 50?

  这么想,比如我最大连接数 100 ,连接池如果也设置 100 ,其他人连接就肯定连不上了。连接池这个 50 是在哪设置?其实是在代码里面,是应用服务自己创建的连接池,是比如说我现在建立一个 50 个连接的连池,应用服务会一直跟 mysql 去沟通:嘿,我还要用这 50 个连接池呢 ,在超时之前,每隔一段时间,跟 mysql 絮叨一回,我还占着呢,你别让别人进来。mysql 接收到这消息之后,就把这50个连接就一直留给这个应用服务。剩下的 50 个连接闲置,谁想用,谁想连就连。

  那么连接池这边,我去传给连接池 一个 SQL 语句,执行了,返回正确结果了。那么下一个 SQL 语句过来,就不用管连接池是否还在等待链接,因为只要返回正确结果了,代表这个操作完成了。就相当于一条队列,我给你 10 条 sql 语句,按照顺序执行就好了,而不是说给你 10 条 sql ,你建立 10 次连接,等 30s 断开,再执行第二条,依次执行到第 10 条,这样效率肯定低。但是如果我通过代码的连接池,我相当于是调用一个功能,我给你 10 条sql ,你给我返回回来结果,返回回来后,你就给我闲置。你就可以开始接下来的操作。

  那么为啥这个连接池要设置 50 ?如果设置成 100 ,结果会怎样?第一个问题,假设数据库挂了,管理员怎么连?所以肯定不能设定为 100 。可以去找找这种连接池的代码,看一看,玩一玩

  

MYSQL数据库默认最大连接数是100,然而对于流量稍微大一点的论坛或网站这个连接数是远远不够的,当并发数过大的时候会出现连接数不够用,使得很多线程在等待其他连接释放,会直接导致导致数据库连接超时或者响应时间过长,所以需要调整最大连接数。

技术分享图片
# 重新设置数据库最大连接数
set global max_connections=1000 

# 查询数据库当前设置的最大连接数
show variables like %max_connections%; 
MariaDB [(none)]> show variables like %max_connections%; 
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| extra_max_connections | 1     |    # extra_port可以接受的最大连接数
| max_connections       | 151   |    # 最大连接数
+-----------------------+-------+
2 rows in set (0.00 sec)

# extra_port是之前5.6版本开始新增的,指定了可以使用的端口


# 服务器响应的最大连接数
show global status like Max_used_connections; 
MariaDB [(none)]> show global status like Max_used_connections; 
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 4     |
+----------------------+-------+
1 row in set (0.00 sec)

# 服务器线程方面的
show status like Threads%;
MariaDB [(none)]> show status like Threads%;
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 0     |    # mysql管理的线程池中还有多少可以被复用的资源
| Threads_connected | 3     |    # 打开的连接数
| Threads_created   | 226   |    # 表示创建过的线程数
| Threads_running   | 1     |    # 激活的连接数,这个数值一般远低于connected数值,
                                # 准确的来说,Threads_running是代表当前并发数
+-------------------+-------+
4 rows in set (0.00 sec)
技术分享图片

 

Mysql监控调优

标签:5.6   资源   引入   value   删除表   连接池   nerd   链接   现在   

原文地址:https://www.cnblogs.com/xiaowenshu/p/10269659.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!