MySQL 参数笔记：参数汇总(持续更新)

一、前言

• 至 5.7.28 版本 MySQL 已经有 517 个参数，有关于元数据、性能、安全等等，那么在配置 MySQL 或者优化的时候就需要了解一些参数的作用再根据业务，配置安全、稳定的 MySQL 实例。这篇博客会收集比较常用的参数进行汇总。

二、MySQL “双一” 安全参数

• innodb_flush_log_at_trx_commit：MySQL 中 “双一” 参数之一，控制 redo 日志的刷盘机制，redo 日志主要作用是来实现事务的持久化存储和 innodb 自动故障恢复，设置不同的参数都可能会对性能和数据安全有影响。

  -- MySQL 默认为 1
  show variables like 'innodb_flush_log_at_trx_commit';
  

  Variable_name	Value
  innodb_flush_log_at_trx_commit	1

  Redo Log：刷写过程 log_buff —mysql写 (write)—> log_file —OS刷新 (flush)—> 磁盘

  ---

  1. innodb_flush_log_at_trx_commit = 0：事务提交时，MySQL不会处理日志缓存区的内容，也不会处理日志文件的刷盘操作，由 MySQL 后台 Master 线程每隔 1 秒将缓存区的数据刷写到redo 日志文件中。延时 1 秒钟写 意味着有丢失最近 1 秒的事务风险。
  2. innodb_flush_log_at_trx_commit = 1：事务提交时，会将日志写入文件中，同时会刷新到磁盘中，保证数据库事务完全不会丢失。实时写，实时刷 这种设置会影响数据库的性能。
  3. innodb_flush_log_at_trx_commit = 2：事务提交时，会将日志缓存区日志写入到文件中，但是不会刷新到磁盘中，而是取决于操作系统的调度。实时写，延迟刷 如果数据库宕机不会出现数据丢失，因为事务已经刷新到 OS cache 操作系统每隔 1 秒会自动刷盘。但是如果系统也出现问题事务没有刷新到磁盘中，那么也会丢失最近 1 秒内的事务数据。

  ---

  从数据库安全角度考虑总结如下：

  Variable_num	数据库宕机	OS宕机
  innodb_flush_log_at_trx_commit = 0	丢失 1s 的数据	丢失 1s 的数据
  innodb_flush_log_at_trx_commit = 1	不会丢失数据	不会丢失数据
  innodb_flush_log_at_trx_commit = 2	不会丢失数据	丢失 1s 的数据

• sync_binlog：MySQL 中 “双一” 参数之一，控制 binlog 的刷写策略。binlog 主要应用于主从复制和配合备份工具恢复数据。binlog 安全也会影响到主从的安全。

  -- MySQL 中默认为 1
  show variables like 'sync_binlog';
  

  Variable_name	Value
  sync_binlog	1

  主从复制：很少有 MySQL 单例支撑业务的情况，大部分 MySQL 应用都是采用集群的方案，进行数据库层面的读写分离，负载均恒或数据备份。而 MySQL 集群本质可以分为两类，一类是依赖 MySQL Replication 的传统集群，另一类是依赖插件(MHA、Galera)真正集群化解决方案 sync_binlog 维护传统主从复制数据安全。

  ---

  1. sync_binlog = 0：事务提交时，将 binlog 信息写入 binlog 文件中(OS Cache) 中，但 MySQL 不控制 Binlog 的刷盘操作，由文件系统自己控制缓存刷盘，这是有一定风险的，如果操作系统宕机，那么 Belog cache 中的 Binlog 数据都会丢失。
  2. sync_binlog = 1：每一个事务提交时，MySQL 都会将 Binlog 刷写到磁盘中，这样，数据库的安全性最高，但是性能损耗是最大的。
  3. sync_binlog = N N>1：表示 N 次提交后，MySQL 会调用文件系统刷盘操作，将 binlog 缓存刷新到磁盘中。如果宕机可能会丢失一部分数据。

  ---

三、MySQL 系统参数

• innodb_buffer_size：InnoDB 引擎最重要的缓存区 buffer_pool 用来存储 InnoDB 索引页面和数据，Undo 页及其它一些辅助数据。它的大小是影响性能的重要因素，官方建议设置为物理内存的 50% ～ 75%。

  -- innodb 引擎最大的内存区域 buffer pool 默认 128 MB
  show variables like 'innodb_buffer_pool_size';
  

  Variable_name	Value
  innodb_buffer_pool_size	134217728

• innodb_buffer_pool_instances：通过这个参数，把原来一整块 Buffer pool 分割成多块内存空间，每个空间管自己的空闲链表、LRU、刷新链表和其它数据结构。这大大增加了并发性，能够有效利用缓存。默认值在 MySQL 5.6.6 取决于 buffer_pool_size 设置大小。

  -- 默认为 1 MySQL 5.6.6 取决于 innodb_buffer_pool_size 的大小
  show variables like 'innodb_buffer_pool_instances';
  

  Variable_name	Value
  innodb_buffer_pool_instances	1

• innodb_log_file_size 和 innodb_log_files_in_group：两个参数共同使用，决定 Redo 物理存储空间的大小。Redo 空间越大可以存储的增量日志也就越大，可以有效降低 Buffer Pool 脏页被淘汰的速度，同时减少 checkpoint 的次数，降低磁盘 IO 的置换率，从而提升数据库的写入效率。Redo 物理空间是 ib_logfile0 和 ib_logfile1 默认两个文件置换使用，可以通过第二个参数进行调整。

  -- Redo 日志物理存储空间大小
  show variables like 'innodb_log_file_size';
  

  Variable_name	Value
  innodb_log_file_size	50331648

  -- 默认为 两个文件置换使用
  show variables like 'innodb_log_files_in_group';
  

  Variable_name	Value
  innodb_log_files_in_group	2

四、性能优化

• Max_connections：MySQL 的最大连接数，如果服务器的并发请求量比较大，可以调高这个值，当然这是要建立在机器能够支撑的情况下，因为如果连接数越来越多，MySQL 会为每个连接提供缓冲区，就会开销的越多的内存，所以需要适当的调整该值，不能随便去提高设值。

  -- 查看 MySQL 最大连接数
  show variables like 'max_connections';
  -- 配置修改方式
  vim /etc/my.cnf 
  Max_connections=1024
  

  Variable_name	Value
  max_connections	151

  设置技巧：可以先打开数据库设置一个比较大的测试值，使用 Max_used_connections 参数观察如果 Max_used_connections 与 max_connections 相同则是因为设置过少或者超出服务负载极限。

  -- 查看当前连接数 与 show processlist 相似
  show status like 'Max_used_connections';
  

  Variable_name	Value
  Max_used_connections	10

• back_log：MySQL 能暂存的连接数量，当 MySQL 线程在一个很短时间内得到非常多的连接请求时候它就会起作用，如果 MySQL 的连接数据达到 max_connections时候，新来的请求将会被存在堆栈中，等待某一连接释放资源，该推栈的存储数量既 back_log，如果等待连接的数量超过 back_log，将不被授予连接资源。

  -- back_log
  show variables like 'back_log';
  -- 配置文件修改
  vim /etc/my.cnf 
  back_log=1024
  

  Variable_name	Value
  back_log	80

  设置技巧：与 max_connections 设置方法相同测试业务查看连接数，通过设置反馈来决定 back_log 是否修改。