mysql与系统优化

时间 2019-12-14

标签 mysql 系统优化栏目 MySQL 繁體版

原文原文链接

1.系统优化工具

1.1 top

实时监控当前操做系统的负载状况的，每秒刷新一次状态,一般会关注三大指标（CPU、MEM、IO）mysql

1.1.1 各项指标说明

load average: 0.00, 0.00, 0.00：总体的负载状况，判断标准，若是值很是高，只能告诉咱们操做系统很繁忙
CPU使用状况：Cpu(s):  0.2%us,  0.2%sy, 99.7%id,  0.0%wa
%id:   CPU空闲的百分比
%us:用户程序，占用的CPU时间片的百分比。咱们认为us%高是好事，但要在cpu正常能力范围内。
%sy:系统程序（和内核工做有关），资源调配，资源管理，内核其余功能的管理（system call）对于比较成熟的操做系统，对sy%应该是占比不多的。咱们认为越少越好。若是飙升，可能说明两件事情，1，系统bug；2，中病毒了
%wa 这个参数越少越好。若是wait高说明了，1，IO很慢（速度慢，全表扫描）二、内存满了OOM（内存小，全表扫描）

Mem:内存使用状况
total：总的内存量
used：已经被使用的内存量
free：空闲的内存空间
buffer：专门负责操做系统当中，与文件修改类操做有关的内存缓冲区（专门负责写操做的），能够被重复利用的内存区域
cached：专门负责操做系统当中，与文件读取有关的缓存区域（专门负责文件读取操做的），对于操做系统可用内存量=free+buffer+cached
used：used=RSS+anon+buffer+cached
linux系统内存划分的三个区域
RSS：常驻内存集，主要负责程序运行须要的内存区域
Page Cache：文件系统缓存，主要负责文件有关的缓冲和缓存，buffer+cached
anon page: 匿名页，主要负责程序之间交互时使用到内存区域
经过如下命令，手工释放全部buffer和cached
echo 3 > /proc/sys/vm/drop_caches 
SWAP：交换分区，当内存紧张的时候，会将内存区域当中的数据临时置换到SWAP中。
默认：在内存使用量达到60%
[root@db02 ~]# cat /proc/sys/vm/swappiness 
60
对于MySQL环境，要尽可能避免swap使用
sysctl.conf 
临时修改：
[root@db02 ~]# echo 0 >/proc/sys/vm/swappiness

1.2 iostat

测试当前环境IO水平
mount /dev/sdb /data
iostat -dm 1 /dev/sdb
dd if=/dev/zero of=/data/bigfilelinux

在优化过程当中，咱们通常会结合CPU和内存的使用状况看IO状态
CPU很是繁忙（MYSQL）：
        一、user 很高
            再看IO水平，正常状况下IO也会很高
            不正常的状况，user很高，可是IO很低？
            在作大量的计算（多表链接查询、排序、分组、子查询很复杂或者很频繁）
        二、wait 很高
           IO不多
            （1）颇有多是全表扫描
            （2）IO有问题（RAID规划或者磁盘IO自己问题）

1.3 vmstat

[root@db03 ~]# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0  28348 122752      0 349308    0    0    60   100  102  101  4  1 94  0  0
 0  0  28348 122752      0 349308    0    0     0     0   38   82  0  1 99  0  0
 0  0  28348 122752      0 349308    0    0     0     0   43   91  0  0 100  0  0
 0  0  28348 122752      0 349308    0    0     0     0   37   78  0  0 100  0  0

1.4 dstat

须要手动安装：yum -y install dstatios

[root@db03 ~]# dstat 
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  4   1  94   0   0   0|  59k  100k|   0     0 |  50B  512B| 101   100 
  0   1  99   0   0   0|   0     0 |  60B  890B|   0     0 |  62   127 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  53   113 
  0   6  94   0   0   0|   0    14M|  60B  346B|   0     0 | 262   132 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  52   117 
  0   1  99   0   0   0|   0     0 |  60B  346B|   0     0 |  60   121 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  60   131 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  68   134 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  51   117 
  0   1  99   0   0   0|   0     0 |  60B  346B|   0     0 |  57   108 
  0   0 100   0   0   0|   0     0 |  60B  346B|   0     0 |  51   112 ^C

2.数据库层面优化工具

基础优化命令工具
（1）mysql
用法举例：
mysql -uroot -p123 -e "show status like '%lock%'"
（2）SHOW ENGINE INNODB STATUS
mysql> show engine innodb status\G
通常关注比较多的：
内存、锁相关
（3）show index:查看索引
mysql> show index from proc; 
（4）Information_Schema:系通通计表
mysql>use Information_Schema
mysql> select * from INNODB_SYS_TABLES;
（5）mysql库下的  innodb_table_stats  innodb_index_stats
mysql> use msyql
ERROR 1049 (42000): Unknown database 'msyql'
mysql> use mysql
mysql> select *  from innodb_table_stats;
(6)  SHOW [SESSION | GLOBAL] STATUS：查看全局会话状诚
(7) SHOW [FULL]  PROCESSLIST(应急调优)
(8) explain
(9) mysqldumpslow （pt-query-diagest）：分析慢日志

深度优化命令工具（扩展）
mysqlslap：压力测试工具
sysbench：压力测试工具
tpcc：压力测试工具
Performance Schema(5.7默认开启)

3.硬件优化

主机：
根据数据库类型
（1）主机CPU选择
    IO密集型：能够处理多并发的CPU类型，特色是核心数量较多，主频中等
              Intel E系列
    CPU密集型：能够处理高性能计算的cpu类型，主频很是高，核心数量中等
              Intel I系列的
    MySQL的线上业务，处理高并发访问的业务。属于IO密集型的业务，因此选择志强系列的CPU更好一些。
    MySQL非线上的业务，数据处理数据分析，属于CPU密集型业务，因此选择I系列的CPU。
（2）内存容量选择
    通常是选择cpu核心数量的2倍
（3）IO的选择
    一、磁盘选择
    SATAIII   SAS   FC  SSD   pci-e SSD  Flash    
    主机 RAID卡的BBU(Battery Backup Unit)关闭
存储（有条件的公司会选择单独存储设备）：
    根据存储数据种类的不一样，选择不一样的存储设备
    配置合理的RAID级别(raid五、raid十、热备盘)
    raid0   ：性能高（条带化），安全性和单盘同样
    raid1   ：安全性高（条带化功能），性能和单盘同样
    raid10  ：读写性能都很高（0级别条带化功能），安全性高（1级别，镜像功能），企业若是有条件推荐的一种raid级别
    raid5   ：较好的安全性（校验），较好的性能（条带化功能，读性能比较高，写性能通常），对于读多写少的业务可使用此级别
高端存储：IBM EMC  HDS，通常都是raid1（就是raid10） ，自带条带化功能，并且只支持4块盘作一个raid
使用合适raid级别，避免过分条带化    
IOPS峰值：对于每一块硬件磁盘来说，都有一个固定参数IOPS，每秒最多可以进行的IO的次数。
网络设备：
    使用流量支持更高的网络设备（交换机、路由器、网线、网卡、HBA卡）
网卡绑定：
    bonding     0(负载,负载的提早是交换机要作堆叠)   1(主备)

4.系统层面优化

一、Swap调整
/proc/sys/vm/swappiness的内容改为0（临时）
echo 0>/proc/sys/vm/swappiness
/etc/sysctl.conf上添加vm.swappiness=0（永久）
vim /etc/sysctl.conf 
vm.swappiness=0
sysctl -p
这个参数决定了Linux是倾向于使用swap，仍是倾向于释放文件系统cache。在内存紧张的状况下，数值越低越倾向于释放文件系统cache。
固然，这个参数只能减小使用swap的几率，并不能避免Linux使用swap。
二、IO调度策略
临时修改：
[root@db02 ~]# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq] 
[root@db02 ~]# echo deadline >/sys/block/sda/queue/scheduler
[root@db02 ~]# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq 
永久修改：
更改到以下内容:
vim /etc/default/grub，添加elevator=deadline
GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap biosdevname=0 net.ifnames=0 elevator=deadline rhgb quiet"
[root@db03 grub]# vim /boot/grub2/grub.cfg
三、关闭无用服务
    chkconfig --level 23456 acpid off
    chkconfig --level 23456 anacron off
    chkconfig --level 23456 autofs off
    chkconfig --level 23456 avahi-daemon off
    chkconfig --level 23456 bluetooth off
    chkconfig --level 23456 cups off
    chkconfig --level 23456 firstboot off
    chkconfig --level 23456 haldaemon off
    chkconfig --level 23456 hplip off
    chkconfig --level 23456 ip6tables off
    chkconfig --level 23456 iptables  off
    chkconfig --level 23456 isdn off
    chkconfig --level 23456 pcscd off
    chkconfig --level 23456 sendmail  off
    chkconfig --level 23456 yum-updatesd  off
以上：硬件优化建议，操做系统优化建议，应该在业务架构搭建初始应该作好。

5.数据库层面优化

MySQL参数优化测试建议

1、参数优化前压力测试
0、优化测试前提
MacBook：虚拟机vm12.5，OS centos 6.9（系统已优化），cpu*2（I5 4288u 2.6GHZ）,MEM*4GB ,HardDisk:Apple SSD(SM-0512F)

一、模拟数据库数据
为了测试咱们建立一个test1的库建立一个tb1的表，而后导入20万行数据，脚本以下：
vim slap.sh
#!/bin/bash  
HOSTNAME="localhost" 
PORT="3306" 
USERNAME="root" 
PASSWORD="123" 
DBNAME="oldboy" 
TABLENAME="lufei" 
#create database 
mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} -e "drop database if exists ${DBNAME}" 
create_db_sql="create database if not exists ${DBNAME}" 
mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} -e "${create_db_sql}" 
#create table 
create_table_sql="create table if not exists ${TABLENAME}(stuid int not null primary key,stuname varchar(20) not null,stusex char(1)   
not null,cardid varchar(20) not null,birthday datetime,entertime datetime,address varchar(100) default null)" 
mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e "${create_table_sql}" 
#insert data to table 
i="1" 
while [ $i -le 200000 ]  
do  
insert_sql="insert into ${TABLENAME}  values($i,''guojialei_$i,'1','110011198809163418','1988-09-16','2017-09-13','oldboyedu_$i')" 
mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e "${insert_sql}" 
let i++  
done  
#select data  
select_sql="select count(*) from ${TABLENAME}" 
mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e "${select_sql}"

执行脚本：
sh slap.sh

二、检查数据可用性
mysql -uroot -p123
select count(*) from test1.tb1;

三、在没有优化以前咱们使用mysqlslap来进行压力测试
mysqlslap --defaults-file=/etc/my.cnf \
 --concurrency=100 --iterations=1 --create-schema='test1' \
--query='select * from test1.tb1' engine=innodb \
--number-of-queries=2000 -uroot -p123 -verbose

Benchmark
    Running for engine rbose
    Average number of seconds to run all queries: 31.463 seconds
    Minimum number of seconds to run all queries: 31.463 seconds
    Maximum number of seconds to run all queries: 31.463 seconds
    Number of clients running queries: 100
    Average number of queries per client: 20
--------------------------------mysqlslap使用说明----------------------------
mysqlslap工具介绍
 mysqlslap来自于mariadb包，测试的过程默认生成一个mysqlslap的schema,生成测试表t1，查询和插入测试数据，mysqlslap库自动生成，若是已经存在则先删除。用--only-print来打印实际的测试过程，整个测试完成后不会在数据库中留下痕迹。

经常使用选项：

--auto-generate-sql, -a 自动生成测试表和数据，表示用mysqlslap工具本身生成的SQL脚原本测试并发压力
--auto-generate-sql-load-type=type 测试语句的类型。表明要测试的环境是读操做仍是写操做仍是二者混合的。取值包括：read，key，write，update和mixed(默认)
--auto-generate-sql-add-auto-increment 表明对生成的表自动添加auto_increment列，从5.1.18版本开始支持
--number-char-cols=N, -x N 自动生成的测试表中包含多少个字符类型的列，默认1
--number-int-cols=N, -y N 自动生成的测试表中包含多少个数字类型的列，默认1
--number-of-queries=N 总的测试查询次数(并发客户数×每客户查询次数)
--query=name,-q 使用自定义脚本执行测试，例如能够调用自定义的存储过程或者sql语句来执行测试
--create-schema 表明自定义的测试库名称，测试的schema，MySQL中schema也就是database
--commint=N 多少条DML后提交一次
--compress, -C 如服务器和客户端都支持压缩，则压缩信息
--concurrency=N, -c N 表示并发量，即模拟多少个客户端同时执行select；可指定多个值，以逗号或者--delimiter参数指定值作为分隔符
--engine=engine_name, -e engine_name 表明要测试的引擎，能够有多个，用分隔符隔开
--iterations=N, -i N 测试执行的迭代次数，表明要在不一样并发环境下，各自运行测试多少次
--only-print 只打印测试语句而不实际执行
--detach=N 执行N条语句后断开重连
--debug-info, -T 打印内存和CPU的相关信息
测试示例：

1）单线程测试

[root@centos7 ~]# mysqlslap -a -uroot -p
Enter password: 
Benchmark
        Average number of seconds to run all queries: 0.004 seconds
        Minimum number of seconds to run all queries: 0.004 seconds
        Maximum number of seconds to run all queries: 0.004 seconds
        Number of clients running queries: 1
        Average number of queries per client: 0
2）多线程测试，使用--concurrency来模拟并发链接

[root@centos7 ~]# mysqlslap -uroot -p -a -c 500
Enter password: 
Benchmark
        Average number of seconds to run all queries: 3.384 seconds
        Minimum number of seconds to run all queries: 3.384 seconds
        Maximum number of seconds to run all queries: 3.384 seconds
        Number of clients running queries: 500
        Average number of queries per client: 0
3）同时测试不一样的存储引擎的性能进行对比

[root@centos7 ~]# mysqlslap -uroot -p -a --concurrency=500 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info
Enter password: 
Benchmark
        Running for engine myisam
        Average number of seconds to run all queries: 0.192 seconds
        Minimum number of seconds to run all queries: 0.187 seconds
        Maximum number of seconds to run all queries: 0.202 seconds
        Number of clients running queries: 500
        Average number of queries per client: 2

Benchmark
        Running for engine innodb
        Average number of seconds to run all queries: 0.355 seconds
        Minimum number of seconds to run all queries: 0.350 seconds
        Maximum number of seconds to run all queries: 0.364 seconds
        Number of clients running queries: 500
        Average number of queries per client: 2


User time 0.33, System time 0.58
Maximum resident set size 22892, Integral resident set size 0
Non-physical pagefaults 46012, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 31896, Involuntary context switches 0
4）执行一次测试，分别500和1000个并发，执行5000次总查询

[root@centos7 ~]# mysqlslap -uroot -p -a --concurrency=500,1000 --number-of-queries 5000 --debug-info
Enter password: 
Benchmark
        Average number of seconds to run all queries: 3.378 seconds
        Minimum number of seconds to run all queries: 3.378 seconds
        Maximum number of seconds to run all queries: 3.378 seconds
        Number of clients running queries: 500
        Average number of queries per client: 10

Benchmark
        Average number of seconds to run all queries: 3.101 seconds
        Minimum number of seconds to run all queries: 3.101 seconds
        Maximum number of seconds to run all queries: 3.101 seconds
        Number of clients running queries: 1000
        Average number of queries per client: 5


User time 0.84, System time 0.64
Maximum resident set size 83068, Integral resident set size 0
Non-physical pagefaults 139977, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 31524, Involuntary context switches 3
5）迭代测试

[root@centos7 ~]# mysqlslap -uroot -p -a --concurrency=500 --number-of-queries 5000 --iterations=5 --debug-info
Enter password: 
Benchmark
        Average number of seconds to run all queries: 3.307 seconds
        Minimum number of seconds to run all queries: 3.184 seconds
        Maximum number of seconds to run all queries: 3.421 seconds
        Number of clients running queries: 500
        Average number of queries per client: 10


User time 2.18, System time 1.58
Maximum resident set size 74872, Integral resident set size 0
Non-physical pagefaults 327732, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 73904, Involuntary context switches 3    
----------------------------------------------------------------------------    



2、优化细节：

一、参数优化
1.1 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   |
    +----------------------+-------+
若是max_used_connections跟max_connections相同,那么就是max_connections设置太低或者超过服务器的负载上限了，低于10%则设置过大.
（3）修改方式举例
vim /etc/my.cnf 
Max_connections=1024

1.2 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

1.3 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=1200
interactive_timeout=1200

1.4 key_buffer_size
（1）简介
key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤为是索引读的速度

（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个请求在内存中没有找到直接从硬盘中读取索引

-----------------------------------------------------
注：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 是否过多，从而认定当前服务器运行情况的优劣。
看如下例子：
在调用mysqldump备份数据时，大概执行步骤以下：
180322 17:39:33       7 Connect     root@localhost on
7 Query       /*!40100 SET @@SQL_MODE='' */
7 Init DB     guo
7 Query       SHOW TABLES LIKE 'guo'
7 Query       LOCK TABLES `guo` READ /*!32311 LOCAL */
7 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
7 Query       show create table `guo`
7 Query       show fields from `guo`
7 Query       show table status like 'guo'
7 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `guo`
7 Query       UNLOCK TABLES
7 Quit


其中，有一步是：show fields from `guo`。从slow query记录的执行计划中，能够知道它也产生了 Tmp_table_on_disk。

因此说，以上公式并不能真正反映到mysql里临时表的利用率，有些状况下产生的 Tmp_table_on_disk 咱们彻底不用担忧，所以不必过度关注 Created_tmp_disk_tables，但若是它的值大的离谱的话，那就好好查一下，你的服务器到底都在执行什么查询了。 
--------------------------------------------
（3）配置方法
key_buffer_size=64M


1.5 query_cache_size
（1）简介：
查询缓存简称QC，使用查询缓冲，mysql将查询结果存放在缓冲区中，从此对于一样的select语句（区分大小写）,将直接从缓冲区中读取结果。
一个sql查询若是以select开头，那么mysql服务器将尝试对其使用查询缓存。
注：两个sql语句，只要想差哪怕是一个字符（列如大小写不同；多一个空格等）,那么这两个sql将使用不一样的一个cache。
（2）判断依据
mysql> show status like "%Qcache%";
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 1       |
| Qcache_free_memory      | 1031360 |
| Qcache_hits             | 0       |
| Qcache_inserts          | 0       |
| Qcache_lowmem_prunes    | 0       |
| Qcache_not_cached       | 2002    |
| Qcache_queries_in_cache | 0       |
| Qcache_total_blocks     | 1       |
+-------------------------+---------+
8 rows in set (0.00 sec)

---------------------状态说明--------------------
Qcache_free_blocks：缓存中相邻内存块的个数。若是该值显示较大，则说明Query Cache 中的内存碎片较多了，FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而获得一个空闲块。
注：当一个表被更新以后，和它相关的cache blocks将被free。可是这个block依然可能存在队列中，除非是在队列的尾部。能够用FLUSH QUERY CACHE语句来清空free blocks
Qcache_free_memory：Query Cache 中目前剩余的内存大小。经过这个参数咱们能够较为准确的观察出当前系统中的Query Cache 内存大小是否足够，是须要增长仍是过多了。
Qcache_hits：表示有多少次命中缓存。咱们主要能够经过该值来验证咱们的查询缓存的效果。数字越大，缓存效果越理想。
Qcache_inserts：表示多少次未命中而后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果insert到查询缓存中。这样的状况的次数越多，表示查询缓存应用到的比较少，效果也就不理想。固然系统刚启动后，查询缓存是空的，这很正常。
Qcache_lowmem_prunes：多少条Query 由于内存不足而被清除出Query Cache。经过“Qcache_lowmem_prunes”和“Qcache_free_memory”相互结合，可以更清楚的了解到咱们系统中Query Cache 的内存大小是否真的足够，是否很是频繁的出现由于内存不足而有Query 被换出。这个数字最好长时间来看；若是这个数字在不断增加，就表示可能碎片很是严重，或者内存不多。（上面的free_blocks和free_memory能够告诉您属于哪一种状况）
Qcache_not_cached：不适合进行缓存的查询的数量，一般是因为这些查询不是 SELECT 语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前Query Cache 中cache 的Query 数量；
Qcache_total_blocks：当前Query Cache 中的block 数量；。
-------------------------------------

（3）配置示例

mysql> show variables like '%query_cache%' ;
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     |
| query_cache_limit            | 1048576 |
| query_cache_min_res_unit     | 4096    |
| query_cache_size             | 1048576 |
| query_cache_type             | OFF     |
| query_cache_wlock_invalidate | OFF     |
+------------------------------+---------+
6 rows in set (0.00 sec)

mysql> 

-------------------配置说明-------------------------------
以上信息能够看出query_cache_type为off表示不缓存任何查询
各字段的解释：
query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小，query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但若是你的查询都是小数据查询，就容易形成内存碎片和浪费。
query_cache_size：查询缓存大小 (注：QC存储的最小单位是1024byte，因此若是你设定了一个不是1024的倍数的值，这个值会被四舍五入到最接近当前值的等于1024的倍数的值。)
query_cache_type：缓存类型，决定缓存什么样的查询，注意这个值不能随便设置，必须设置为数字，可选项目以及说明以下：
若是设置为0，那么能够说，你的缓存根本就没有用，至关于禁用了。
若是设置为1，将会缓存全部的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。
若是设置为2，则只缓存在select语句中经过SQL_CACHE指定须要缓存的查询。

修改/etc/my.cnf,配置完后的部分文件以下：
query_cache_size=256M
query_cache_type=1

-----------------------------------------------------
1.6 max_connect_errors
max_connect_errors是一个mysql中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码等状况，当超过指定次数，mysql服务器将禁止host的链接请求，直到mysql服务器重启或经过flush hosts命令清空此host的相关信息 max_connect_errors的值与性能并没有太大关系。

修改/etc/my.cnf文件，在[mysqld]下面添加以下内容
max_connect_errors=2000

1.7 sort_buffer_size
（1）简介：
每一个须要进行排序的线程分配该大小的一个缓冲区。增长这值加速ORDER BY 或GROUP BY操做，
（2）配置依据
Sort_Buffer_Size并非越大越好，因为是connection级的参数，过大的设置+高并发可能会耗尽系统内存资源。
列如：500个链接将会消耗500*sort_buffer_size（2M）=1G内存
（3）配置方法
 修改/etc/my.cnf文件，在[mysqld]下面添加以下：
sort_buffer_size=1M

1.8 max_allowed_packet
（1）简介：
mysql根据配置文件会限制，server接受的数据包大小。
（2）配置依据：
有时候大的插入和更新会受max_allowed_packet参数限制，致使写入或者更新失败，更大值是1GB，必须设置1024的倍数
（3）配置方法：
max_allowed_packet=32M

1.9 join_buffer_size

用于表间关联缓存的大小，和sort_buffer_size同样，该参数对应的分配内存也是每一个链接独享。

1.10 thread_cache_size 
(1)简介
服务器线程缓存，这个值表示能够从新利用保存在缓存中线程的数量,当断开链接时,那么客户端的线程将被放到缓存中以响应下一个客户而不是销毁(前提是缓存数未达上限),若是线程从新被请求，那么请求将从缓存中读取,若是缓存中是空的或者是新的请求，那么这个线程将被从新建立,若是有不少新的线程，增长这个值能够改善系统性能.
（2）配置依据
经过比较 Connections 和 Threads_created 状态的变量，能够看到这个变量的做用。
设置规则以下：1GB 内存配置为8，2GB配置为16，3GB配置为32，4GB或更高内存，可配置更大。
服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)

试图链接到MySQL(无论是否链接成功)的链接数
mysql>  show status like 'threads_%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 8     |
| Threads_connected | 2     |
| Threads_created   | 4783  |
| Threads_running   | 1     |
+-------------------+-------+
4 rows in set (0.00 sec)
Threads_cached :表明当前此时此刻线程缓存中有多少空闲线程。
Threads_connected :表明当前已创建链接的数量，由于一个链接就须要一个线程，因此也能够当作当前被使用的线程数。
Threads_created:表明从最近一次服务启动，已建立线程的数量，若是发现Threads_created值过大的话，代表MySQL服务器一直在建立线程，这也是比较耗资源，能够适当增长配置文件中thread_cache_size值。
Threads_running :表明当前激活的（非睡眠状态）线程数。并非表明正在使用的线程数，有时候链接已创建，可是链接处于sleep状态。
(3)配置方法：
thread_cache_size=32

1.11 innodb_buffer_pool_size
（1）简介
对于InnoDB表来讲，innodb_buffer_pool_size的做用就至关于key_buffer_size对于MyISAM表的做用同样。
（2）配置依据：
InnoDB使用该参数指定大小的内存来缓冲数据和索引。
对于单独的MySQL数据库服务器，最大能够把该值设置成物理内存的80%,通常咱们建议不要超过物理内存的70%。
mysql> SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%'
+---------------------------------------+-------------+
| Variable_name                         | Value       |
+---------------------------------------+-------------+
| Innodb_buffer_pool_dump_status        | not started |
| Innodb_buffer_pool_load_status        | not started |
| Innodb_buffer_pool_pages_data         | 1557        |
| Innodb_buffer_pool_bytes_data         | 25509888    |
| Innodb_buffer_pool_pages_dirty        | 0           |
| Innodb_buffer_pool_bytes_dirty        | 0           |
| Innodb_buffer_pool_pages_flushed      | 2305        |
| Innodb_buffer_pool_pages_free         | 63977       |
| Innodb_buffer_pool_pages_misc         | 2           |
| Innodb_buffer_pool_pages_total        | 65536       |
| Innodb_buffer_pool_read_ahead_rnd     | 0           |
| Innodb_buffer_pool_read_ahead         | 64          |
| Innodb_buffer_pool_read_ahead_evicted | 0           |
| Innodb_buffer_pool_read_requests      | 32036288    |
| Innodb_buffer_pool_reads              | 600         |
| Innodb_buffer_pool_wait_free          | 0           |
| Innodb_buffer_pool_write_requests     | 280891      |
+---------------------------------------+-------------+
17 rows in set (0.00 sec)

mysql>
Innodb_buffer_pool_pages_data
The number of pages in the InnoDB buffer pool containing data. The number includes both dirty and
clean pages.

Innodb_buffer_pool_pages_total
The total size of the InnoDB buffer pool, in pages.

Innodb_page_size
InnoDB page size (default 16KB). Many values are counted in pages; the page size enables them to be
easily converted to bytes





（3）配置方法
innodb_buffer_pool_size=1024M

1.12 innodb_flush_log_at_trx_commit
（1）简介
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、一、2三个。
0，表示当事务提交时，不作日志写入操做，而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次；
1，则在每秒钟或是每次事物的提交都会引发日志文件写入、flush磁盘的操做，确保了事务的ACID；
2，每次事务提交引发写入日志文件的动做，但每秒钟完成一次flush磁盘操做。
（2）配置依据

实际测试发现，该值对插入数据的速度影响很是大，设置为2时插入10000条记录只须要2秒，设置为0时只须要1秒，而设置为1时则须要229秒。所以，MySQL手册也建议尽可能将插入操做合并成一个事务，这样能够大幅提升速度。
根据MySQL官方文档，在容许丢失最近部分事务的危险的前提下，能够把该值设为0或2。
（3）配置方法
innodb_flush_log_at_trx_commit=1

1.13 innodb_thread_concurrency 
（1）简介
此参数用来设置innodb线程的并发数量，默认值为0表示不限制。
（2）配置依据
在官方doc上，对于innodb_thread_concurrency的使用，也给出了一些建议，以下：
若是一个工做负载中，并发用户线程的数量小于64，建议设置innodb_thread_concurrency=0；
若是工做负载一直较为严重甚至偶尔达到顶峰，建议先设置innodb_thread_concurrency=128，
并经过不断的下降这个参数，96, 80, 64等等，直到发现可以提供最佳性能的线程数，
例如，假设系统一般有40到50个用户，但按期的数量增长至60，70，甚至200。你会发现，
性能在80个并发用户设置时表现稳定，若是高于这个数，性能反而降低。在这种状况下，
建议设置innodb_thread_concurrency参数为80，以免影响性能。
若是你不但愿InnoDB使用的虚拟CPU数量比用户线程使用的虚拟CPU更多（好比20个虚拟CPU），
建议经过设置innodb_thread_concurrency 参数为这个值（也可能更低，这取决于性能体现），
若是你的目标是将MySQL与其余应用隔离，你能够考虑绑定mysqld进程到专有的虚拟CPU。
可是需 要注意的是，这种绑定，在myslqd进程一直不是很忙的状况下，可能会致使非最优的硬件使用率。在这种状况下，
你可能会设置mysqld进程绑定的虚拟 CPU，容许其余应用程序使用虚拟CPU的一部分或所有。
在某些状况下，最佳的innodb_thread_concurrency参数设置能够比虚拟CPU的数量小。
按期检测和分析系统，负载量、用户数或者工做环境的改变可能都须要对innodb_thread_concurrency参数的设置进行调整。

（3）配置方法：
innodb_thread_concurrency=8


1.14 innodb_log_buffer_size

此参数肯定些日志文件所用的内存大小，以M为单位。缓冲区更大能提升性能，对于较大的事务，能够增大缓存大小。
innodb_log_buffer_size=8M


1.15. innodb_log_file_size = 50M
此参数肯定数据日志文件的大小，以M为单位，更大的设置能够提升性能.

1.16. innodb_log_files_in_group = 3
为提升性能，MySQL能够以循环方式将日志文件写到多个文件。推荐设置为3

1.17.read_buffer_size = 1M
MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。若是对表的顺序扫描请求很是频繁，而且你认为频繁扫描进行得太慢，能够经过增长该变量值以及内存缓冲区大小提升其性能。和 sort_buffer_size同样，该参数对应的分配内存也是每一个链接独享

18.read_rnd_buffer_size = 1M
 MySql的随机读（查询操做）缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以免磁盘搜索，提升查询速度，若是须要排序大量数据，可适当调高该值。但MySql会为每一个客户链接发放该缓冲空间，因此应尽可能适当设置该值，以免内存开销过大。
 注：顺序读是指根据索引的叶节点数据就能顺序地读取所须要的行数据。随机读是指通常须要根据辅助索引叶节点中的主键寻找实际行数据，而辅助索引和主键所在的数据段不一样，所以访问方式是随机的。

19.bulk_insert_buffer_size = 8M
批量插入数据缓存大小，能够有效提升插入效率，默认为8M

1.20.binary log
log-bin=/data/mysql-bin
binlog_cache_size = 2M //为每一个session 分配的内存，在事务过程当中用来存储二进制日志的缓存, 提升记录bin-log的效率。没有什么大事务，dml也不是很频繁的状况下能够设置小一点，若是事务大并且多，dml操做也频繁，则能够适当的调大一点。前者建议是--1M，后者建议是：即 2--4M
max_binlog_cache_size = 8M //表示的是binlog 可以使用的最大cache 内存大小
max_binlog_size= 512M //指定binlog日志文件的大小，若是当前的日志大小达到max_binlog_size，还会自动建立新的二进制日志。你不能将该变量设置为大于1GB或小于4096字节。默认值是1GB。在导入大容量的sql文件时，建议关闭sql_log_bin，不然硬盘扛不住，并且建议按期作删除。

expire_logs_days = 7 //定义了mysql清除过时日志的时间。
二进制日志自动删除的天数。默认值为0,表示“没有自动删除”。



innodb_max_dirty_pages_pct        ***********
innodb_additional_mem_pool_size (于2G内存的机器，推荐值是20M。32G内存的?100M)
transaction_isolation            *********


1.21 安全参数

Innodb_flush_method=(O_DIRECT, fdatasync) 

        一、fdatasync    ：
        （1）在数据页须要持久化时，首先将数据写入OS buffer中，而后由os决定何时写入磁盘
        （2）在redo buffuer须要持久化时，首先将数据写入OS buffer中，而后由os决定何时写入磁盘
            但，若是innodb_flush_log_at_trx_commit=1的话，日志仍是直接每次commit直接写入磁盘
        二、 Innodb_flush_method=O_DIRECT
         （1）在数据页须要持久化时，直接写入磁盘
         （2）在redo buffuer须要持久化时，首先将数据写入OS buffer中，而后由os决定何时写入磁盘
            但，若是innodb_flush_log_at_trx_commit=1的话，日志仍是直接每次commit直接写入磁盘

最高安全模式：
        innodb_flush_log_at_trx_commit=1
        innodb_flush_method=O_DIRECT
最高性能模式：
        innodb_flush_log_at_trx_commit=0
        innodb_flush_method=fdatasync

通常状况下，咱们更偏向于安全。

“双一标准”
        innodb_flush_log_at_trx_commit=1        ***************
        sync_binlog=1                            ***************
        innodb_flush_method=O_DIRECT






3、参数优化结果
[mysqld]
basedir=/application/mysql
datadir=/application/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=1024M
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    

再次压力测试    ：

[root@db02 ~]# mysqlslap --defaults-file=/etc/my.cnf \
>  --concurrency=100 --iterations=1 --create-schema='test1' \
> --query='select * from test1.tb1' engine=innodb \
> --number-of-queries=2000 -uroot -p123 -verbose
Warning: Using a password on the command line interface can be insecure.
Benchmark
    Running for engine rbose
    Average number of seconds to run all queries: 7.271 seconds
    Minimum number of seconds to run all queries: 7.271 seconds
    Maximum number of seconds to run all queries: 7.271 seconds
    Number of clients running queries: 100
    Average number of queries per client: 20
对比以前：
mysqlslap --defaults-file=/etc/my.cnf \
 --concurrency=100 --iterations=1 --create-schema='test1' \
--query='select * from test1.tb1' engine=innodb \
--number-of-queries=2000 -uroot -p123 -verbose

Benchmark
    Running for engine rbose
    Average number of seconds to run all queries: 31.463 seconds
    Minimum number of seconds to run all queries: 31.463 seconds
    Maximum number of seconds to run all queries: 31.463 seconds
    Number of clients running queries: 100
    Average number of queries per client: 20