Mysql监控调优

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

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

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

查询走硬盘的话,硬盘会影响性能。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)

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

时间: 2024-07-31 05:10:46

Mysql监控调优的相关文章

MySQL性能调优与架构设计——第 18 章 高可用设计之 MySQL 监控

第 18 章 高可用设计之 MySQL 监控 前言: 一个经过高可用可扩展设计的 MySQL 数据库集群,如果没有一个足够精细足够强大的监控系统,同样可能会让之前在高可用设计方面所做的努力功亏一篑.一个系统,无论如何设计如何维护,都无法完全避免出现异常的可能,监控系统就是根据系统的各项状态的分析,让我们能够尽可能多的提前预知系统可能会出现的异常状况.即使没有及时发现将要发生的异常,也要在异常出现后的第一时间知道系统已经出现异常,否则之前的设计工作很可能就白费了. 18.1 监控系统设计 系统监控

数据库服务器mysql性能调优

mysql性能调优分为4个方面 一.硬件(CPU   内存   硬盘)监控CPU  内存 硬盘的值.[[email protected] ~]# toptop - 03:58:11 up 10:05,  1 user,  load average: 0.00, 0.00, 0.00Tasks: 121 total,   1 running, 120 sleeping,   0 stopped,   0 zombieCpu(s):  0.0%us,  0.7%sy,  0.0%ni, 99.0%i

[转]MySQL性能调优与架构设计&mdash;&mdash;第11章 常用存储引擎优化

第11章 常用存储引擎优化 前言: MySQL 提供的非常丰富的存储引擎种类供大家选择,有多种选择固然是好事,但是需要我们理解掌握的知识也会增加很多.每一种存储引擎都有各自的特长,也都存在一定的短处.如何将各种存储引擎在自己的应用环境中结合使用,扬长避短,也是一门不太简单的学问.本章选择最为常用的两种存储引擎进行针对性的优化建议,希望能够对读者朋友有一定的帮助. 11.1 MyI SAM存储引擎优化 我们知道,MyISAM存储引擎是MySQL最为古老的存储引擎之一,也是最为流行的存储引擎之一.对

MySQL性能调优与架构设计——第11章 常用存储引擎优化

第11章 常用存储引擎优化 前言: MySQL 提供的非常丰富的存储引擎种类供大家选择,有多种选择固然是好事,但是需要我们理解掌握的知识也会增加很多.每一种存储引擎都有各自的特长,也都存在一定的短处.如何将各种存储引擎在自己的应用环境中结合使用,扬长避短,也是一门不太简单的学问.本章选择最为常用的两种存储引擎进行针对性的优化建议,希望能够对读者朋友有一定的帮助. 11.1 MyI SAM存储引擎优化 我们知道,MyISAM存储引擎是MySQL最为古老的存储引擎之一,也是最为流行的存储引擎之一.对

MySQL性能调优与架构设计——第12章 可扩展设计的基本原则

第12章 可扩展设计的基本原则 前言: 随着信息量的飞速增加,硬件设备的发展已经慢慢的无法跟上应用系统对处理能力的要求了.此时,我们如何来解决系统对性能的要求?只有一个办法,那就是通过改造系统的架构体系,提升系统的扩展能力,通过组合多个低处理能力的硬件设备来达到一个高处理能力的系统,也就是说,我们必须进行可扩展设计.可扩展设计是一个非常复杂的系统工程,所涉及的各个方面非常的广泛,技术也较为复杂,可能还会带来很多其他方面的问题.但不管我们如何设计,不管遇到哪些问题,有些原则我们还是必须确保的.本章

实现MySQL读写分离,MySQL性能调优

实现MySQL读写分离 1.1 问题 本案例要求配置2台MySQL服务器+1台代理服务器,实现MySQL代理的读写分离: 用户只需要访问MySQL代理服务器,而实际的SQL查询.写入操作交给后台的2台MySQL服务器来完成 其中Master服务器允许SQL查询.写入,Slave服务器只允许SQL查询 1.2 方案 使用4台RHEL 7.2虚拟机,如图-1所示.其中192.168.4.10.192.168.4.20分别作为MySQL主.从服务器,是整个服务的后端:另一台 192.168.4.100

Database基础(六):实现MySQL读写分离、MySQL性能调优

一.实现MySQL读写分离 目标: 本案例要求配置2台MySQL服务器+1台代理服务器,实现MySQL代理的读写分离: 用户只需要访问MySQL代理服务器,而实际的SQL查询.写入操作交给后台的2台MySQL服务器来完成 其中Master服务器允许SQL查询.写入,Slave服务器只允许SQL查询 方案: 使用4台RHEL 7.2虚拟机,如下图所示.其中192.168.4.10.192.168.4.20分别作为MySQL主.从服务器,是整个服务的后端:另一台 192.168.4.100作为MyS

主从同步、读写分离、mysql性能调优(软优化)

配置mysql主从同步1 主从同步的作用:让slave身份的数据库服务器自动同步 master身份的数据库服务器上的数据. 一.主数据库服务器的配置192.168.4.121 用户授权mysql> grant replication slave on *.* to [email protected]"192.168.4.11" identified by "123456";2 启用binlog日志vim /etc/my.cnf[mysqld]server_id

MySQL数据库调优经验

?RDS for MySQL 由亚洲唯一WebScaleSQL团队维护内核源码,结合阿里巴巴多年MySQL数据库调优经验,从数据库源码层及数据库参数进行了性能优化,在相近规格配置下,RDS for MySQL性能值能达到自建数据库性能的3倍以上. RDS for MySQL针对通用的场景,在内核做了一系列的优化: 1. 改进了InnoDB redo组提交功能,多线程并发写入的情况下能有10%以上的速度提升. 2. 优化锁,对一些会引起串行化的大锁进行了拆分,能够有效避免长时间的读锁等待,提升数据