优化介绍
准备一台MySQL的虚拟机环境，最好修改为4G内存，4核CPU
image
启动3306节点的 mysql,并导入t100w的库
t100w库 共享地址 提取密码:999
环境准备
cpu:4 , mem:8G , mysql:5.7.26全新环境
压力测试准备
/etc/init.d/mysqld start
mysql < t100w.sql
mysqladmin -uroot -p password 123
mysqlslap --defaults-file=/etc/my.cnf \
--concurrency=100 --iterations=1 --create-schema='test' \
--query="select * from test.t100w where k2='FGCD'" engine=innodb \
--number-of-queries=2000 -uroot -p123 -verbose
image
优化哲学
为什么
`为了获得成就感?
为了证实比系统设计者更懂数据库?
为了从优化成果来证实优化者更有价值?
NO!NO!NO!NO!NO!NO!
但通常事实证实的结果往往会和您期待相反！
优化有风险，涉足需谨慎！`
优化风险
优化不总是对一个单纯的环境进行！还很可能是一个复杂的已投产的系统。
优化手段本来就有很大的风险，只不过你没能力意识到和预见到！
任何的技术可以解决一个问题，但必然存在带来一个问题的风险！
对于优化来说解决问题而带来的问题控制在可接受的范围内才是有成果。
保持现状或出现更差的情况都是失败！
稳定性和业务可持续性通常比性能更重要！
优化不可避免涉及到变更，变更就有风险！
优化使性能变好，维持和变差是等概率事件！
优化不能只是数据库管理员担当风险，但会所有的人分享优化成果！
所以优化工作是由业务需要驱使的！！！
谁参与
DBA—数据库管理员(系统,硬件,网路,存储,代码,架构思维)
数据库管理员
业务部门代表
应用程序架构师
应用程序设计人员
应用程序开发人员
硬件及系统管理员
存储管理员
优化的方向
安全方向优化（业务持续性）
性能方向优化（业务高效性）
优化的范围及思路
优化范围：
存储、主机和操作系统:
主机架构稳定性
I/O规划及配置
Swap
OS内核参数
网络问题
应用程序:（Index，lock，session）
应用程序稳定性和性能
SQL语句性能
串行访问资源
性能欠佳会话管理
数据库优化:（内存、数据库设计、参数）
内存
数据库结构(物理&逻辑)
实例配置
架构设计 :
性能 : 读写分离,分布式
安全 : 主备,多活
安全&性能 : 分布式,NewSQL
image
优化工具和命令
系统层面
CPU：top
top命令：
%CPU %MEM COMMAND
400.0 4.3 mysqld
%Cpu(s): 99.0 us, 1.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
按1键 展开:
%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu(s): 99.0 us, 1.0 sy, 0.0 id, 0.0 wa
0.0 id : CPU空闲的百分比
5% 以上,还是有空闲的.
99.0 us : 用户程序占用的CPU百分比
对于mysql程序,处理数据.
1.0 sy : 内核程序占用的CPU百分比
资源管理,资源调度等,计算.
sys过高: 锁,并发连接数较高,数据处理分析应用
0.0 wa : 花在等待的CPU时间
IO方面出了问题
锁.大事务
IO本身: IOPS达到峰值
[root@db01 ~]# top -H -p 9846
MEM
Swap: 1560568 total, 1560568 free, 0 used. 7386000 avail Mem
IO:
[root@db01 ~]# iostat -dk 1
Linux 3.10.0-957.el7.x86_64 (db01) 08/23/2019 _x86_64_ (4 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 1.65 36.24 115.44 223266 711168
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.00 0.00 0.00 0 0
数据库层面
基础优化:
show status
show variables
show index
show processlist
show slave status
show engine innodb status
desc /explain
slowlog
扩展类深度优化:
pt系列
mysqlslap
sysbench
information_schema
performance_schema
sys
优化思路分解
硬件优化
真实的硬件（PC Server）: DELL R系列 ，华为，浪潮，HP，联想
云产品：ECS、数据库RDS、DRDS
IBM 小型机 P6 570 595 P7 720 750 780 P8
CPU根据数据库类型
OLTP
OLAP
IO密集型：线上系统，OLTP主要是IO密集型的业务，高并发
CPU密集型：数据分析数据处理，OLAP，cpu密集型的，需要CPU高计算能力（i系列，IBM power系列）
CPU密集型： I 系列的，主频很高，核心少
IO密集型： E系列（至强），主频相对低，核心数量多
内存
建议2-3倍cpu核心数量 （ECC）
磁盘选择
SATA-III SAS Fc SSD（sata） pci-e ssd Flash
主机 RAID卡的BBU(Battery Backup Unit)关闭
存储
根据存储数据种类的不同，选择不同的存储设备
配置合理的RAID级别(raid5、raid10、热备盘)
r0 :条带化 ,性能高
r1 :镜像，安全
r5 :校验+条带化，安全较高+性能较高（读），写性能较低 （适合于读多写少）
r10：安全+性能都很高，最少四块盘，浪费一半的空间（高IO要求）
HDS
EMC2(DELL)
IBM
DELL 华为
网络
1、硬件买好的（单卡单口）
2、网卡绑定（bonding），交换机堆叠
主备模式: mode=1
负载均衡: mode=0
注意: 多交换机要做堆叠.
以上问题，提前规避掉。
操作系统优化
Swap调整
cat /proc/sys/vm/swappiness
临时
echo 0 >/proc/sys/vm/swappiness
永久
vim /etc/sysctl.conf
vm.swappiness=0
sysctl -p
这个参数决定了Linux是倾向于使用swap，还是倾向于释放文件系统cache。在内存紧张的情况下，数值越低越倾向于释放文件系统cache。
当然，这个参数只能减少使用swap的概率，并不能避免Linux使用swap。
修改MySQL的配置参数innodb_flush_method，开启O_DIRECT模式
这种情况下，InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘，但是redo log依旧会使用文件系统cache。值得注意的是，Redo log是覆写模式的，即使使用了文件系统的cache，也不会占用太多
IO调度策略
centos 7 默认是deadline
cat /sys/block/sda/queue/scheduler
#临时修改为deadline(centos6)
echo deadline >/sys/block/sda/queue/scheduler
vi /boot/grub/grub.conf
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet
IO ：
raid
no lvm
ext4或xfs
ssd
IO调度策略
提前规划好以上所有问题，减轻MySQL优化的难度。
应用端
- 开发过程规范,标准
- 减少烂SQL:不走索引,复杂逻辑,切割大事务.
- 避免业务逻辑错误,避免锁争用.
这个阶段,需要我们DBA深入业务,或者要和开发人员\业务人员配合实现
优化,最根本的是"优化"人.
----oldguo
MySQL参数优化测试
虚拟机vm12.5，OS centos 6.9（系统已优化），cpu4（I5 4440 3.1GHZ）,MEM4GB ,HardDisk:SSD
参数优化细节：
max_connections 最大连接数
key_buffer_size 临时表
innodb_flush_log_at_trx_commit 双一:redo log的刷写策略,每次事务提交时,首先刷写os buffer,立即刷写到磁盘.
innodb_buffer_pool_size 数据缓冲区大小,建议不要超过物理内存80%
max_allowed_packet 允许最大数据包的大小
sync_binlog 双一:二进制日志的刷写策略,每次事务提交理解刷写二进制日志
innodb_flush_method
刷写策略:
O_DIRECT :
刷写buffer pool 绕过OS buffer ,直接刷磁盘
刷写redo buffer 先到OS buffer ,再到磁盘
Max_connections *****
（1）简介
Mysql的最大连接数，如果服务器的并发请求量比较大，可以调高这个值，当然这是要建立在机器能够支撑的情况下，因为如果连接数越来越多，mysql会为每个连接提供缓冲区，就会开销的越多的内存，所以需要适当的调整该值，不能随便去提高设值。
（2）判断依据
show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 |
+-----------------+-------+
show status like 'Max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 101 |
+----------------------+-------+
（3）修改方式举例
vim /etc/my.cnf
Max_connections=1024
补充:
1.开启数据库时,我们可以临时设置一个比较大的测试值
2.观察show status like 'Max_used_connections';变化
3.如果max_used_connections跟max_connections相同,
那么就是max_connections设置过低或者超过服务器的负载上限了，
低于10%则设置过大.
back_log ***
（1）简介
mysql能暂存的连接数量，当主要mysql线程在一个很短时间内得到非常多的连接请求时候它就会起作用，如果mysql的连接数据达到max_connections时候，新来的请求将会被存在堆栈中，等待某一连接释放资源，该推栈的数量及back_log,如果等待连接的数量超过back_log，将不被授予连接资源。
back_log值指出在mysql暂时停止回答新请求之前的短时间内有多少个请求可以被存在推栈中，只有如果期望在一个短时间内有很多连接的时候需要增加它
（2）判断依据
show full processlist
发现大量的待连接进程时，就需要加大back_log或者加大max_connections的值
（3）修改方式举例
vim /etc/my.cnf
back_log=1024
wait_timeout和interactive_timeout ****
（1）简介
wait_timeout：指的是mysql在关闭一个非交互的连接之前所要等待的秒数
interactive_timeout：指的是mysql在关闭一个交互的连接之前所需要等待的秒数，比如我们在终端上进行mysql管理，使用的即使交互的连接，这时候，如果没有操作的时间超过了interactive_time设置的时间就会自动的断开，默认的是28800，可调优为7200。
wait_timeout:如果设置太小，那么连接关闭的就很快，从而使一些持久的连接不起作用
（2）设置建议
如果设置太大，容易造成连接打开时间过长，在show processlist时候，能看到很多的连接 ，一般希望wait_timeout尽可能低
（3）修改方式举例
wait_timeout=60
interactive_timeout=7200
长连接的应用，为了不去反复的回收和分配资源，降低额外的开销。
一般我们会将wait_timeout设定比较小，interactive_timeout要和应用开发人员沟通长链接的应用是否很多。如果他需要长链接，那么这个值可以不需要调整。
另外还可以使用类外的参数弥补。
key_buffer_size *****
（1）简介
key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度
《1》此参数与myisam表的索引有关
《2》内存临时表的创建有关（多表链接、子查询中、union）
在有以上查询语句出现的时候，需要创建临时表，用完之后会被丢弃
临时表有两种创建方式：
内存中------->key_buffer_size
磁盘上------->ibdata1(5.6)
ibtmp1 (5.7）
（2）设置依据
通过key_read_requests和key_reads可以直到key_baffer_size设置是否合理。
mysql> show variables like "key_buffer_size%";
+-----------------+---------+
| Variable_name | Value |
+-----------------+---------+
| key_buffer_size | 8388608 |
+-----------------+---------+
1 row in set (0.00 sec)
mysql>
mysql> show status like "key_read%";
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 10 |
| Key_reads | 2 |
+-------------------+-------+
2 rows in set (0.00 sec)
mysql>
一共有10个索引读取请求，有2个请求在内存中没有找到直接从硬盘中读取索引
控制在 5%以内 。
注：key_buffer_size只对myisam表起作用，即使不使用myisam表，但是内部的临时磁盘表是myisam表，也要使用该值。
可以使用检查状态值created_tmp_disk_tables得知：
mysql> show status like "created_tmp%";
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 6 |
| Created_tmp_tables | 1 |
+-------------------------+-------+
3 rows in set (0.00 sec)
mysql>
通常地，我们习惯以 Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables)
Created_tmp_disk_tables/(Created_tmp_disk_tables + Created_tmp_tables)
或者已各自的一个时段内的差额计算，来判断基于内存的临时表利用率。所以，我们会比较关注 Created_tmp_disk_tables 是否过多，从而认定当前服务器运行状况的优劣。
Created_tmp_disk_tables/(Created_tmp_disk_tables + Created_tmp_tables)
控制在5%-10%以内
参数优化结果
vim /etc/my.cnf
[mysqld]
basedir=/data/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
log-error=/var/log/mysql.log
log_bin=/data/binlog/mysql-bin
binlog_format=row
skip-name-resolve
server-id=52
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
relay_log_purge=0
max_connections=1024
back_log=128
wait_timeout=60
interactive_timeout=7200
key_buffer_size=16M
query_cache_size=64M
query_cache_type=1
query_cache_limit=50M
max_connect_errors=20
sort_buffer_size=2M
max_allowed_packet=32M
join_buffer_size=2M
thread_cache_size=200
innodb_buffer_pool_size=2048M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=32M
innodb_log_file_size=128M
innodb_log_files_in_group=3
binlog_cache_size=2M
max_binlog_cache_size=8M
max_binlog_size=512M
expire_logs_days=7
read_buffer_size=2M
read_rnd_buffer_size=2M
bulk_insert_buffer_size=8M
[client]
socket=/tmp/mysql.sock
再次压力测试 ：
mysqlslap --defaults-file=/etc/my.cnf --concurrency=100 --iterations=1 --create-schema='oldboy' --query="select * from oldboy.t_100w where k2='FGCD'" engine=innodb --number-of-queries=200000 -uroot -p123 -verbose
锁的监控及处理
锁等待模拟
概念：
Record Lock
Next Lock
GAP Lock
X
IX
S
IS
tx1:
USE oldboy
UPDATE t_100w SET k1='av' WHERE id=10;
## tx2:
USE oldboy
UPDATE t_100w SET k1='az' WHERE id=10;
监控锁状态
vim /etc/my.cnf
innodb_lock_wait_timeout=28800
image
看有没有锁等待
SHOW STATUS LIKE 'innodb_row_lock%';
查看哪个事务在等待(被阻塞了)
USE information_schema
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state='LOCK WAIT';
trx_query : 被阻塞的语句是谁
trx_mysql_thread_id: 被阻塞的会话ID
查看锁源,谁锁的我!
SELECT * FROM sys.innodb_lock_waits; ## ====>被锁的和锁定它的之间关系
## waiting_pid : 等待的会话线程号
## waiting_query : 等待的语句
## blocking_pid : 锁源的线程号 :2
## sql_kill_blocking_query : 处理建议
## sql_kill_blocking_connection: 处理建议
找到锁源的thread_id
SELECT * FROM performance_schema.threads WHERE processlist_id=2;
## THREAD_ID = 27
找到锁源的SQL语句
-- 当前在执行的语句
SELECT * FROM performance_schema.`events_statements_current` WHERE thread_id=27;
主从优化：
## 5.7 从库多线程MTS
基本要求:
5.7以上的版本(忘记小版本)
必须开启GTID
binlog必须是row模式
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
5.7 :
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8
索引
简单SQL语句
max_connections 最大连接数
key_buffer_size 临时表
innodb_flush_log_at_trx_commit 双一:redo log的刷写策略,每次事务提交时,首先刷写os buffer,立即刷写到磁盘.
innodb_buffer_pool_size 数据缓冲区大小,建议不要超过物理内存80%
max_allowed_packet 允许最大数据包的大小
sync_binlog 双一:二进制日志的刷写策略,每次事务提交理解刷写二进制日志
innodb_flush_method
O_DIRECT :
刷写buffer pool 绕过OS buffer ,直接刷磁盘
刷写redo buffer 先到OS buffer ,再到磁盘
优化项目:锁的监控及处理
背景:
硬件环境: DELL R720,E系列16核,48G MEM,SAS900G6,RAID10
在例行巡检时,发现9-11点时间段的CPU压力非常高(80-90%)
项目的职责
>1.通过top详细排查,发现mysqld进程占比达到了700-800%
2.其中有量的CPU是被用作的SYS和WAIT,us处于正常
3.怀疑是MySQL 锁 或者SQL语句出了问题
4.经过排查slowlog及锁等待情况,发现有大量锁等待及少量慢语句
(1) pt-query-diagest 查看慢日志
(2) 锁等待有没有?
db03 [(none)]>show status like 'innodb_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+-------------------------------+-------+
情况一:
有100多个current_waits,说明当前很多锁等待情况
情况二:
1000多个lock_waits,说明历史上发生过的锁等待很多
5 查看那个事务在等待(被阻塞了)
6 查看锁源事务信息(谁锁的我)
7 找到锁源的thread_id
8 找到锁源的SQL语句
找到语句之后,和应用开发人员进行协商
>(1)开发人员描述,此语句是事务挂起导致
我们提出建议是临时kill 会话,最终解决问题
(2)
开发人员查看后,发现是业务逻辑问题导致的死锁,产生了大量锁等待
临时解决方案,将阻塞事务的会话kill掉.
最终解决方案,修改代码中的业务逻辑
项目结果:
经过排查处理,锁等待的个数减少80%.解决了CPU持续峰值的问题.
锁监控设计到的命令:
show status like 'innodb_rows_lock%'
select * from information_schema.innodb_trx;
select * from sys.innodb_lock_waits;
select * from performance_schema.threads;
select * from performance_schema.events_statements_current;
select * from performance_schema.events_statements_history;
死锁监控
show engine innodb status\G
show variables like '%deadlock%';
vim /etc/my.cnf
innodb_print_all_deadlocks = 1