1、优化哲学
1.1 优化风险
优化不总是对一个单纯的环境进行！还很可能是一个复杂的已投产的系统。
优化手段本来就有很大的风险，只不过你没能力意识到和预见到！
任何的技术可以解决一个问题，但必然存在带来一个问题的风险！
对于优化来说解决问题而带来的问题控制在可接受的范围内才是有成果。
保持现状或出现更差的情况都是失败！稳定性和业务可持续性通常比性能更重要！
优化不可避免涉及到变更，变更就有风险！
优化使性能变好，维持和变差是等概率事件！
优化不能只是数据库管理员担当风险，但会所有的人分享优化成果！
所以优化工作是由业务需要驱使的！！！
1.2 谁参与优化？
- 数据库管理员
- 业务部门代表
- 应用程序架构师
- 应用程序设计人员
- 应用程序开发人员
- 硬件及系统管理员
- 存储管理员
1.3 优化方向
安全优化（业务持续性）
性能优化（业务高效性）
1.4 优化范围及思路
优化范围：
存储、主机和操作系统:
主机架构稳定性
I/O规划及配置
Swap
OS内核参数
网络问题应用程序:（Index，lock，session）
应用程序稳定性和性能
SQL语句性能
串行访问资源
性能欠佳会话管理数据库优化:（内存、数据库设计、参数）
内存
数据库结构(物理&逻辑)
实例配置
1.5 优化效果和成本的评估
image.png
优化成本由上往下依次增高
优化效果由下往上依次增高
- 由以上图示可以看出，我们如果想要深度优化Mysql数据库，需要做的事情不是单方面的，而是要从成本及优化效果选择最适合当前企业需求的方案。
2、优化工具的使用
2.1 优化工具介绍----定位问题
操作系统层面
top、iostat、vmstat、nmon、dstat数据库基础优化命令工具
mysql
show [session | global] status
show engine innodb status
show processlist
show index
information schema
explain
mysqladmin
mysqlshow深度优化命令工具
mysqlslap
sysbench
mysql profiling
performance schema
tpcc
pt-query-diagest
2.2 优化工具使用说明
1、top
cpu使用情况的平均值：
image.png
CPU每个核心的分别使用的情况（按1）：
image.png
%id (CPU的空闲程度)：
只要在cpu工作能力之内，我们cpu越繁忙越好，最好不要低于10%。但是一般，我们购买cpu，一般会冗余30%-40%
0.0 us：用户的程序占用的cpu时间比例
在cpu能力范围内，越高越好。但是会有意外情况，需要继续观察IO
0.0 sy：系统调用占用的cpu比例
越低越好，如果很高，可能是bug，也有可能是中病毒了
0.0 wa：cpu等待的时间比例
越低越好，wa高的原因:
- 数据从磁盘加载到内存慢
- IO 慢
- 数据量大（大事务）
- 内存小
- 等待锁
- 多cpu使用情况监控：
主要判断我们cpu多核心有没有被充分利用。
现象：单颗很忙，其他很闲，对于MySQL来讲，有可能是并发参数设定不合理导致的。
2、内存：
image.png
buffer:数据缓存区，负责修改类的数据缓冲。
cache:缓存，负责查询类的数据的缓存。
buff/cache ：文件系统缓存
slab Allocator 分配器
buddy system 内存管理子系统
total= free + used +buffer + cache
used = Rss + Anonymous
PAGE = buffer + cache
程序=指令+数据
- 对于page cache来讲(OS buffer)
- 内存的可用空间的计算 free +buffer cache
- 内存回收(buffer)的方式:
Linux 6操作系统，默认回收策略（buffer cache），不立即释放内存，偏向于使用swap分区
内存使用达到60% 时候，会使用swap分区
Linux 7操作系统
内存使用达到70% 时候，才会时候swap分区
- 查看swap使用的开关值
cat /proc/sys/vm/swappiness
30
对于数据库服务器来讲，建议关闭swap 的使用，偏向于释放buffer和cache，提供更多的可用内存空间。
echo 0 >/proc/sys/vm/swappiness 的内容改成0（临时）
# 永久关闭
vim /etc/sysctl.conf
添加:
vm.swappiness=0
sysctl -p
3、iostat：查看IO
[root@db01 ~]# iostat
Linux 3.10.0-957.el7.x86_64 (db01) 02/12/2020 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.55 0.00 0.40 0.01 0.00 99.04
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 6.81 195.04 4.90 321847 8093
scd0 0.01 0.62 0.00 1028 0
dm-0 0.05 1.49 0.00 2460 0
dm-1 4.39 187.79 3.66 309888 6045
[root@db01 ~]# iostat -dk 1
Linux 3.10.0-957.el7.x86_64 (db01) 02/12/2020 _x86_64_ (4 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 6.79 194.57 4.90 321847 8113
scd0 0.01 0.62 0.00 1028 0
dm-0 0.05 1.49 0.00 2460 0
dm-1 4.38 187.34 3.67 309888 6065
dd if=/dev/zero of=/tmp/bigfile bs=1M count=4096
iostat -dm 1
IO结合cpu一起查看：
IO 高 cpu us% 也高,属于正常现象
CPU us高 IO很低，read 和 write少，IOPS高，由于过度条带化
iops：每块磁盘的每秒的IO的数量us% wait 高 ，IO read 和 write 少，tps不高
对于数据库来说：
锁
随机IO过多
排序、分组、多表达
3 优化思路分解
3.1 硬件优化
主机（真实的硬件+ 云产品ECS，数据库（RDS、DRDS））
真实的硬件（PC Server）: DELL R系列 ，华为，浪潮，HP，联想
云产品：ECS、数据库RDS、DRDS
IBM 小型机 P6 570 595 P7 720 750 780 P8cpu选择
CPU密集型：数据分析数据处理，OLAP，cpu密集型的，需要CPU高计算能力
IO密集型：线上系统，OLTP主要是IO密集型的业务，高并发
CPU密集型： I 系列的，主频很高，核心少 （多是家庭用）
IO密集型： E系列（至强），主频相对低，核心数量多
对于数据库服务器，偏向IO密集型，处理高并发业务内存容量选择：建议2-3倍cpu核心数量，尽量选择带有ECC校验的内存；例如：cpu8核，内存选16G-32G,
磁盘选择：STAT-III SAS(企业级，应用最多) Fc SSD(sata) pci-e ssd Flash
如果数据库是存在本地，不是存在存储上的话，主机 RAID卡的BBU(电池备用单元)功能关闭，跳过缓存，直接写在磁盘上，防止数据损坏。
- 存储
配置合理的RAID级别(raid5、raid10、热备盘)
r0 :条带化 ,性能高
r1 :镜像，安全
r5 :校验+条带化，安全较高+性能较高（读），写性能较低 （适合于读多写少）
r10：安全+性能都很高，最少四块盘，浪费一半的空间（高IO要求）
一般应用raid 5、raid 10，raid 10 性能最好。读多写少的话用raid 5，IO要求高的话用raid 10.
- 网络：
1、硬件买好的（单卡单口）
2、网卡绑定（bonding），交换机堆叠
以上问题，提前规避掉。
3.2 操作系统优化
- swap调整
echo 0 >/proc/sys/vm/swappiness的内容改成0（临时），
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，不用调整
1) centos6 临时修改为deadline
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
2) 查询
cat /sys/block/sda/queue/scheduler
- 操作系统IO调整：
raid
no lvm（不使用lvm）
ext4或xfs文件系统
ssd 存储
IO调度策略
提前规划好以上所有问题，减轻MySQL优化的难度。
3.3 MySQL参数优化
- 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设置过低或者超过服务器的负载上限了，Max_used_connections低于max_connections10%则设置过大。
- back_log
（1）简介
mysql能暂存的连接数量；如果mysql的连接数据达到max_connections时候，新来的请求将会被存在堆栈中，等待某一连接释放资源；
如果等待连接的数量超过back_log，将不被授予连接资源。
back_log是max_connection的一个辅助参数，只有如果期望在一个短时间内有很多连接的时候需要增加它
（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）修改方式举例
wait_timeout=60
interactive_timeout=1200
长连接的应用，为了不去反复的回收和分配资源，降低额外的开销。
（3）设置建议
在show processlist时候，一般我们会将wait_timeout设定尽可能低；interactive_timeout要和应用开发人员沟通长链接的应用是否很多。如果他需要长链接，那么这个值可以不需要调整。另外还可以使用类外的参数弥补。
- key_buffer_size
（1）简介
key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度
《1》此参数只与myisam表的索引缓冲有关
《2》临时表的创建有关
创建临时表使用场景：order by、join、子查询中、distinct、union 等SQL语句操作，用完之后临时表会被丢弃
临时表有两种创建方式：
内存中------->key_buffer_size
磁盘上------->ibdata1(5.6)
ibtmp1 (5.7）
（2）设置依据
通过key_read_requests 和 key_reads可以直到key_buffer_size设置是否合理。
mysql> show variables like "key_buffer_size%"; //查看索引缓冲区的大小
+-----------------+---------+
| Variable_name | Value |
+-----------------+---------+
| key_buffer_size | 8388608 |
+-----------------+---------+
1 row in set (0.00 sec)
mysql> show status like "key_read%"; //查看索引请求状态
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 10 |
| Key_reads | 2 |
+-------------------+-------+
2 rows in set (0.00 sec)
# 一共有10个索引读取请求，有2个请求从硬盘中读取的索引（在内存中没有找到索引）
- 我们希望在内存中生成临时表，不希望在硬盘中产生的临时表
注：key_buffer_size只对myisam表起作用，即使不使用myisam表，但是内部的临时磁盘表是myisam表，也要使用该值。
可以使用检查状态值created_tmp_disk_tables得知：
mysql> show status like "created_tmp%"; //查询temp表的使用情况
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 6 |
| Created_tmp_tables | 1 |
+-------------------------+-------+
3 rows in set (0.00 sec)
Created_tmp_tables //在内存中生成的临时表的个数
Created_tmp_disk_tables //在磁盘中生成临时表的个数
Created_tmp_disk_tables/(Created_tmp_disk_tables + Created_tmp_tables) //磁盘生成的临时表的占比
Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables) //内存生成的临时表的占比
- 我们会比较关注 Created_tmp_disk_tables 是否过多，从而认定当前服务器运行状况的优劣。
Created_tmp_disk_tables/(Created_tmp_disk_tables + Created_tmp_tables) 磁盘生成的临时表的占比控制在10%以内
（3）配置方法
key_buffer_size=64M //测试值，要做严格的压力测试
- 看以下例子：
在调用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 TABLESguoREAD /!32311 LOCAL /
7 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1
7 Query show create tableguo
7 Query show fields fromguo
7 Query show table status like 'guo'
7 Query SELECT /!40001 SQL_NO_CACHE */ * FROMguo
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，但如果它的值大的离谱的话，那就好好查一下，你的服务器到底都在执行什么查询了。
- query_cache_size
（1）简介：
查询缓存简称QC，使用查询缓冲，mysql将查询结果存放在缓冲区中，今后对于同样的select语句（区分大小写）,将直接从缓冲区中读取结果。
SQL层：
select * from t1 where name=:NAME;
select * from t1 where name=:NAME;
1、查询完结果之后，会对SQL语句进行hash运算，得出hash值,我们把他称之为SQL_ID
2、会将存储引擎返回的结果+SQL_ID存储到缓存中。
存储方式：
例子：select * from t1 where id=10; 100次
1、将select * from t1 where id=10; 进行hash运算计算出一串hash值，我们把它称之为“SQL_ID"
2、将存储引擎返回上来的表的内容+SQLID存储到查询缓存中
使用方式：
1、一条SQL执行时，进行hash运算，得出SQLID，去找query cache
2、如果cache中有，则直接返回数据行，如果没有，就走原有的SQL执行流程
一个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：表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。
情况1：如果命中较高，说明确实需要加大查询缓存。
情况2：如果命中率低，说明缓存作用不大，这时加大就是浪费空间。
Qcache_inserts：表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果insert到查询缓存中。这样的情况的次数越多，表示查询缓存应用到的比较少，效果也就不理想。当然系统刚启动后，查询缓存是空的，这很正常。
Qcache_lowmem_prunes：
多少条Query因为内存不足而被清除出QueryCache。通过“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 数量；
* Qcache_free_blocks 来判断碎片
Qcache_free_memory + Qcache_lowmem_prunes 来判断内存够不够
命中率 Qcache_hits / (Qcache_inserts+Qcache_not_cached+Qcache_hits)
如果出现hits比例过低，其实就可以关闭查询缓存了。使用redis专门缓存数据库
（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)
-------------------配置说明-------------------------------
各字段的解释：
query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小，query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。
query_cache_size：查询缓存大小 (注：QC存储的最小单位是1024byte，所以如果你设定了一个不是1024的倍数的值，这个值会被四舍五入到最接近当前值的等于1024的倍数的值。)
query_cache_type：缓存类型，决定缓存什么样的查询，注意这个值不能随便设置，必须设置为数字，可选项目以及说明如下：
如果设置为off表示不缓存任何查询
如果设置为0，那么可以说，你的缓存根本就没有用，相当于禁用了。
如果设置为1，将会缓存所有的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。
如果设置为2，则只缓存在select语句中通过SQL_CACHE指定需要缓存的查询。
* 修改/etc/my.cnf,配置完后的部分文件如下：
query_cache_size=128M
query_cache_type=1
- max_connect_errors
max_connect_errors是一个mysql中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码等情况，当超过指定次数，mysql服务器将禁止host的连接请求，直到mysql服务器重启或通过flush hosts命令清空此host的相关信息 max_connect_errors的值与性能并无太大关系。
配置：
vim /etc/my.cnf
[mysqld]
max_connect_errors=2000
- sort_buffer_size
（1）简介：
每个需要进行排序的线程单独分配一个缓冲区。增加这值加速
ORDER BY
GROUP BY
distinct
union
（2）配置依据
Sort_Buffer_Size并不是越大越好，由于是connection级的参数，过大的设置+高并发可能会耗尽系统内存资源。
列如：500个连接将会消耗500*sort_buffer_size（2M）=1G内存
（3）配置方法
修改/etc/my.cnf文件，在[mysqld]下面添加如下：
sort_buffer_size=1M
- max_allowed_packet
（1）简介：
mysql根据配置文件会限制，server端接受的数据包大小。
（2）配置依据：
有时候大的插入和更新会受max_allowed_packet参数限制，导致写入或者更新失败，更大值是1GB，必须设置1024的倍数
（3）配置方法：
max_allowed_packet=32M
以上是服务端的包大小限制，影响的是写的操作；客户端影响的是读的操作。
例子：mysqldump --max_allowed_packet=128M
- join_buffer_size
select a.name,b.name from a join b on a.id=b.id where xxxx
用于表间关联缓存的大小，和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享。
尽量在SQL与方面进行优化，效果较为明显。
优化的方法：在on条件列加索引，至少应当是有MUL索引
- 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服务器一直在创建线程，这也是比较耗cpu SYS资源，可以适当增加配置文件中thread_cache_size值。
Threads_running :代表当前激活的（非睡眠状态）线程数。并不是代表正在使用的线程数，有时候连接已建立，但是连接处于sleep状态。
(3)配置方法：
thread_cache_size=32
整理：
Threads_created ：一般在架构设计阶段，会设置一个测试值，做压力测试。
结合zabbix监控，看一段时间内此状态的变化。
如果在一段时间内，Threads_created趋于平稳，说明对应参数设定是OK。
如果一直陡峭的增长，或者出现大量峰值，那么继续增加此值的大小，在系统资源够用的情况下（内存）
- innodb_buffer_pool_size（重要）
（1）简介
对于InnoDB表数据和索引的缓存大小
（2）配置依据
InnoDB使用该参数指定大小的内存来缓冲数据和索引。
对于单独的MySQL数据库服务器，最大可以把该值设置成物理内存的80%,一般我们建议不要超过物理内存的70%。
（3）查看
show engine innodb status\G
show variables like 'innodb_buffer_pool_size'
（4）配置方法
innodb_buffer_pool_size=2048M
使用压力测试：
QPS：query per seconds 每秒能做多少次select
TPS：transaction per seconds 每秒能做多少次事务
- innodb_flush_log_at_trx_commit（重要）
（1）简介
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。
0，表示当事务提交时，不做日志写入操作，而是每秒钟将缓存中的数据写入缓存并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，redo刷写磁盘的参数，双1标准中的一个1
- innodb_thread_concurrency
（1）简介
此参数用来设置并发连接的线程数量，默认值为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与其他应用隔离，你可以l考虑绑定mysqld进程到专有的虚拟CPU。
但是需 要注意的是，这种绑定，在myslqd进程一直不是很忙的情况下，可能会导致非最优的硬件使用率。在这种情况下，
你可能会设置mysqld进程绑定的虚拟 CPU，允许其他应用程序使用虚拟CPU的一部分或全部。
在某些情况下，最佳的innodb_thread_concurrency参数设置可以比虚拟CPU的数量小。
定期检测和分析系统，负载量、用户数或者工作环境的改变可能都需要对innodb_thread_concurrency参数的设置进行调整。
128 -----> top cpu
设置标准：
1、当前系统cpu使用情况，均不均匀
top
2、当前的连接数，有没有达到顶峰
show status like 'threads_%';
show processlist;
（3）配置方法：
innodb_thread_concurrency=8
方法:
1. 看top ,观察每个cpu的各自的负载情况
2. 发现不平均,先设置参数为cpu个数,然后不断增加(一倍)这个数值
3. 一直观察top状态,直到达到比较均匀时,说明已经到位了.
- innodb_log_buffer_size
此参数确定redo-log缓冲区大小，以M为单位。缓冲区更大能提高性能，对于较大的事务，可以增大缓存大小。
innodb_log_buffer_size=8M //默认8M
监控：show engine innodb status\G
Log sequence number 1626223
Log flushed up to 1626223
Pages flushed up to 1626223
如果数据一致，说明缓存刷写到磁盘很及时。
此参数应用场景：事务提交时有没有花费大量时间
1、大事务：
2、多事务
- innodb_log_file_size = 100M
设置 ib_logfile0 ib_logfile1
此参数确定数据日志文件的大小，以M为单位，更大的设置可以提高性能.
innodb_log_file_size = 100M
IO繁忙的话此参数可以设置大一些,建议值：128M、256M
- innodb_log_files_in_group = 3
为提高性能，MySQL可以以循环方式将日志写到多个日志文件，性能提高。推荐设置为3
- read_buffer_size = 1M
MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。和 sort_buffer_size一样，该参数对应的分配内存也是每个连接独享
- read_rnd_buffer_size = 1M
MySql的随机读（查询操作）缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
注：顺序读是指根据索引的叶节点数据就能顺序地读取所需要的行数据。随机读是指一般需要根据辅助索引叶节点中的主键寻找实际行数据，而辅助索引和主键所在的数据段不同，因此访问方式是随机的。
- bulk_insert_buffer_size = 8M
批量插入数据缓存大小，可以有效提高插入效率，默认为8M
tokuDB percona
myrocks
RocksDB
TiDB
MongoDB
- 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,表示“没有自动删除”。
log-bin=/data/mysql-bin
binlog_format=row
sync_binlog=1
双1标准(基于安全的控制)：
sync_binlog=1 什么时候刷新binlog到磁盘，每次事务commit
innodb_flush_log_at_trx_commit=1
set sql_log_bin=0;
show status like 'com_%';
- 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 内存大小，当超过8M,则会阻塞后面的操作
max_binlog_size= 512M //指定binlog日志文件的大小，如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。你不能将该变量设置为大于1GB或小于4096字节。默认值是1GB。在导入大容量的sql文件时，建议关闭sql_log_bin，否则硬盘扛不住，而且建议定期做删除。
expire_logs_days = 7 //定义了mysql清除过期日志的时间。
二进制日志自动删除的天数，根据全备的周期取设置
log-bin=/data/mysql-bin
binlog_format=row
sync_binlog=1
- 双1标准(基于安全的控制)：
sync_binlog=1 1代表：每次事务commit时候，必然会将binlog刷写到磁盘的日志文件
innodb_flush_log_at_trx_commit=1 每次事务commit时候，必然会将redo写入到磁盘
两个都等于0，是高性能模式
binlog记录的是SQL语句（物理层），redo-log记录的内存数据页的变化（逻辑层）
- 安全参数（重要）
Innodb_flush_method=(O_DIRECT, fsync)
1、fsync ：
（1）在数据页需要持久化时，首先将数据写入OS buffer中，然后由os决定什么时候写入磁盘
（2）在redo buffuer需要持久化时，首先将数据写入OS buffer中，然后由os决定什么时候写入磁盘
但，如果innodb_flush_log_at_trx_commit=1的话，日志还是直接每次commit直接写入磁盘
2、 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=fsync
一般情况下，我们更偏向于安全。
“双一标准”
innodb_flush_log_at_trx_commit=1 ***************
sync_binlog=1 ***************
innodb_flush_method=O_DIRECT