Optimized range and ideas
Optimized range
Storage, and host operating systems:
Host architecture Stability:
I / O planning and configuration
swap
OS kernel parameters (network problems)
Application (index, lock, session)
Application stability and performance
SQL statement performance
Serial access to resources
Poor performance session management
:( memory database optimization, database design, parameter)
RAM
Database structure (physical & logical)
Examples of configuration
Assess the effectiveness and cost optimization:
2, optimizing the use of tools
2.1 system level (top, iostat, vmstat, free)
cpu：
us: the user program, accounting for cpu time during operation, used. We hope that the higher the better, try to control 90%.
sys: Control: resource management, core work (system call)
Reasons for the high sys: 1, bug in the virus; 2 lock problems
id: cup idle time
wa: cpu time spent waiting on
WA: reasons for the high: 1, locks, 2, IO (raid, over striping) 3, Index
Multi-cpu usage monitoring:
The main judge is multi-core cpu we have not been fully utilized.
Phenomenon: other single busy very busy for sql is concerned, may be complicated parameter settings caused unreasonable.
Disk Selection
STAT-III SAS FC SSD（sate） pci-e ssd flash
Host RAID card BBU (battery backup unit) closed
The system used a separate disk data disk tray
storage:
The kind of the synchronization data store, selection of different storage devices
Reasonable allocation RAID level (raid, raid10, hot spare)
r0: striping, high performance
r1: Mirror, Security
r5: + parity strips, high safety + higher performance (read) Write a lower performance (less suitable for reading and writing)
r10: Security + performance are high, at least four discs, wasted half the space (high IO)
iostat: Command Result
Description phenomenon:
1, IO high cpu us also high, is a normal phenomenon
2、cpu us高 IO很低，mysql 不再做增删改查，有可能是存储过程、函数、排序、分组、多表连接
3、waiit，sys 高，IO 低： IO出问题了，锁等待过多的几率比较大。
IOPS： 每秒磁盘最多能够发生的IO 次数，每个磁盘都有一个最大的IOPS。
频繁小事务，IOPS 很高，达到阈值，可能IO吞吐量超过IO 最大吞吐量。
规划可能有问题。
数据库优化使用的命令：
show status;
show global status;
show variables like '';
show proceelist;
show slave status;
show master status;
desc/explain
slow log
show engine innodb status;
扩展类深度优化：
pt系列
mysqlslap
sysbench
information_schema
performance_schema
sys
优化思路分解
硬件优化：
主机：
真实的硬件（pc server）： dell R系统，华为，浪潮，HP，联想
云产品： ECS，数据库RDS、DRDS
IBM 小型机 P6 570 595 ，P7 720 750 ，P8
CPU 根据数据库类型：
OLTP：
OLAP：
IO密集型： 线上系统，OLTP 主要是IO密集型的业务，高并发
CPU密集型： 数据分析数据处理，OLAP，cpu密集型的 需要cup高计算能力（英特尔 I系列，BIN power系统）
CPU 密集型： I 系统的，主频很高，核心少
IO 密集型： E系列（志强），主频相对低，核心数量多。
内存：
内存数/cpu核心数=2～3 倍
网络：
1、硬件买好的（单卡单口）
2、网卡绑定、交换机锥跌
以上问题，提前避免
网卡绑定：绑定时选择的模式（主备模式）。
操作系统优化：
swap 调整
echo '0' >proc/sys/vm/swappiness (临时）
/etc/sysctl.conf
vm.swappiness=0
#sysctl -p
IO模式： 选择deadline 模式
centos7 默认是deadline
cat /sys/block/sda/queue/scheduler
centos6
临时修改：
echo "deadline" > /sys/block/sda/queue/scheduler
永久：
vi /boot/grub/grub.conf
更改到如下内容：
kernel /boot/vmlinuz-2.6.18-8.el5 root=LABEL=/ elevator=deadline rhgb quiet
IO：
raid
no lvm （不要使用，有安全隐患）
ext4 或xfs （ext4 可以使用文件句柄找回来）
ssd
IO 调度策略
提前规划好以上所有问题，减轻mysql优化的难度
应用端：
1、开发过程规范，标准
2、减少烂SQL： 不走索引，复杂逻辑，切割大事务
3、避免业务逻辑错误，避免锁争用。
4、这个阶段，需要我们DBA深入业务，或者要和开发人员、业务人员配合实现。
优化、最根本的是"优化人"
-------oldguo
MySQL 参数优化测试
虚拟机vm12.5 OS centos6.9 （系统以优化） cpu × 4（I5 4440 3.1GHZ） men = 4G SSD：
1、max_connections (默认151）
mysql 的最大连接数，如果服务器的并发请求量比较大，可以适当的调高这个数值。该值并不是越大越好，
设置过大反而会导致mysql消耗大量内存，引起内存泄漏。
这个参数什么时候需要调整，可以根据max_used_connections 参数进行调整
max_connections=1024
show status like 'max_used_connections";
这个参数设置多少根据服务器的配置，主要是内存的大小；
2、back_log *** (达到最大连接数后，在锥荐中临时保存多少连接在排队，在此排队的不会报错too many connection）
3、wait_timeout 和interactive_timeout （默认是28800 8h）
wait_timeout: 指的是mysql在关闭一个非交换的连接之前所要等到的秒数
interactive_timeout: 指的是mysql在关闭一个交换的连接之前所需要等到的秒数。如果设置太小，那么连接关闭的就很快，从而使一些持久的连接不起作用。设置过长连接过多占用连接资源。
2）设置建议
如果设置太大，容易造成连接打开时间过长，在show processlit 时候，能看到很多的连接。
3） 修改方式举例
wait_timeout=60
interactive_timeout=1800
长连接的应用，为了不去反复的回收和分配资源，降低额外的开销。
一般我们会将wait_timeout 设定比较小，interactive_timeout 要和应用开发人员沟通链接的应用是否是长连接，另外还可以使用类似的参数弥补。
4） key_buffer_size *****
1)key_buffer_size 指定索引缓冲区的大小，他决定索引处理的速度，尤其是索引读的速度。
× 此参数与myisam表的索引有关
× 临时表的创建有关（多表连接、子查询中、union）
在有以上查询语句出现的时候，需要创建临时表，用完之后会被丢弃
临时表有两种创建方式：
内存中------------------key_buffer_size
磁盘 -----------------------ibdata1（5.6)
ibtmp1(5.7)
设置依据：
通过key_read_requests 和key_reads 可以直到key_buffer_size 设置是否合理
show variables like 'key_buffer_size%';
show status like 'created_tmp%';
通过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%以内
看以下例子：
在调用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设置方法：
key_buffer_size = 64M; (微调）
5） query_cache_size \query_cache_type = off (默认关闭）
query_cache_size=64M;
query_cache_type=on;
（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：表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。
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_hits / (Qcache_inserts+Qcache_not_cached+Qcache_hits)
90/ 10000 0 90
如果出现hits比例过低，其实就可以关闭查询缓存了。使用redis专门缓存数据库
Qcache_free_blocks 来判断碎片
Qcache_free_memory + Qcache_lowmem_prunes 来判断内存够不够
Qcache_hits 多少次命中 Qcache_hits / (Qcache_inserts+Qcache_not_cached+Qcache_hits)
（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=128M
query_cache_type=16) max_connect_errors ***
max_connect_errors 是一个mysql中与安全有关的计数器值，他负责阻止客户端暴力破解密码等情况，当超过设置的次数后，
mysql 服务器将禁止该host的连接请求，直到mysql服务器重启或通过flush hosts 命令情况此host的相关信息max_connect_errors
的值与性能并无太大的关系。
7) sort_buffer_size *** (
每个需要进行排序的线程分配该大小的一个缓冲区。增加这个值加速
order by
group by
distinct
union
配置依据：（线程级）
sort_buffer_size 并不是越大越好，由于是connection级的参数。设置值过大可能会占用大量的内存 sort_buffer_size * 并发数。
如果sort_buffer_size=2M; 时 如果有500个并发就会立即占用1G的内存。
sort_buffer_size=1M;
SQL语句优化才是关键，SQL语句优化好了就不需要太大值。
8）max_allow_packet *****
mysql 根据配置文件会限制，server 接受的数据包的大小
配置依据
有时候大的插入和更新会受max_allowed_packet 的值限制,最大值1GB
配置方法： max_allowed_packet=32M;
9 ） 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）
join_buffer_size=1M;
10） thread_cache_size *****
服务器线程缓存，这个值表示可以重新利用保存在缓存中线程的数量，当断开连接时，那么用户端的线程将被放到缓存中以响应
下一个用户的请求而不是销毁（前提是缓存数量为达到设置的上限），如果线程重新被请求，那么请求将从缓存中读取，
如果缓存中是空的或者是新的请求，那么这个线程将被重新创建，如果有很多新的线程，增加这个值可以改善系统性能。（连接池、连接重用减轻系统频繁关闭或开启线程的开销）
配置依据，
通过比较（connections 和threads_created 状态的变量，可以看到这个变量的作用。
设置规则如下： 1G内存配置为8，2G内存配置为16，3G内存配置为32，4G内存或更高内存可以配置更大。服务器处理客户的线程将会缓存起来以响应下一个用户的请求（前提是缓存数未达到上限）
试图连接到Mysql （不管是否连接成功） 的连接数
show status like ’threads_%';
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。
如果一直陡峭的增长，或者出现大量峰值，那么继续增加此值的大小，在系统资源够用的情况下（内存）
11) innodb_buffer_pool_size ××××
对于Innodb表来说，innodb_buffer_pool_size 的作用相当于key_buffer_size 对于Myisam表的作用。
innodb_buffer_pool_size 设置为服务器内存的70-80%左右。
innodb 使用该参数指定大小的内存来缓存数据和索引。
12） innodb-flush_log_at_trx_commit=1 ******
说明： 主要控制了innodb 将log buffer 中的数据写入日志文件并flush 磁盘的时间点，取值分别为：0，1，2.
0： 表示当事务提交时，不做日志写入操作，而是每秒将log buffer 中的数据写入binlog文件并刷入到磁盘；
1：每次事务的提交都会引起写入redo日志文件并刷新到磁盘，确保了事务的ACID（完整性）；
2： 每次事务提交会触发redo日志文件的写入，但每秒完成一次flush 磁盘操作。
配置依据：
实际测试发现，该值对插入数据的速度影响非常大，设置为2时插入10000条记录只需要2秒，设置为0时只需要1秒，而设置为1时则需要229秒。因此mysql 手册也建议尽量将多个插入操作合并成一个事务，这样可以大幅提高速度。
如果允许mysql丢失部分数据的情况下可以把该值设置为0或2.
配置方法：
innodb_flush_log_at_trx_commit=1; (双一标准中的一个)
13 ） innodb_thread_concurrency **** (）cpu并发数量是否平均
（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与其他应用隔离，你可以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状态,直到达到比较均匀时,说明已经到位了.14) innodb_log_buffer_size=128M （内存换IO）
设置依据：
1、大事务： 存储过程调用CALL
2、多事务：
15) innodb_log_file_size=200M
设置 ib_logfile0 ib_logfile1
此参数确定数据日志文件的大小以M为单位，更大的设置可以提高性能.
innodb_log_file_in_group=3
为提高性能，Mysql 可以循环方式将日志文件写道多个文件。推荐设置为3-5
设置ib_logifle0 ib_logfile1
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
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,表示“没有自动删除”。
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_%';
安全参数*****
Innodb_filush_method=(O_SYNC,O_DSYNC,O_DIRECT)
1、默认是fsync：
1）在数据页需要持久化时，首先将数据写入os buffer 中，然后由os决定什么时候写入磁盘
2）在redo buffer 需要持久化时，首先将数据写入os buffer 中，然后有os 决定什么时候写入磁盘，但是
如果innodb_flush_log_at_trx_commit=1 的话，日志还是直接每次commit 后直接写入磁盘
2、O_DIRECT
1) 在数据页需要持久化时，直接写入磁盘
2） 在redo buffer需要持久化时，首先将数据写入os buffer中，然后由os决定什么时候写入磁盘，但是
如果innodb_flush_log_at_trx_commit=1 的话，日志还是在commit 之后直接写入磁盘。
最安全的模式：
innodb_flush_log_at_trx_commit=1
sync_binlog=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