Mysql性能参数优化

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 |

+----------------------+-------+

（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%则设置过大.

2.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=1200

长连接的应用，为了不去反复的回收和分配资源，降低额外的开销。

一般我们会将wait_timeout设定比较小，interactive_timeout要和应用开发人员沟通长链接的应用是否很多。如果他需要长链接，那么这个值可以不需要调整。

另外还可以使用类外的参数弥补。

3.innodb_buffer_pool_size

（1）简介

对于InnoDB表来说，innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。

（2）配置依据：

InnoDB使用该参数指定大小的内存来缓冲数据和索引。

对于单独的MySQL数据库服务器，最大可以把该值设置成物理内存的80%,一般我们建议不要超过物理内存的70%。

（3）配置方法

innodb_buffer_pool_size=2048M

4.innodb_flush_log_at_trx_commit

（1）简介

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。

0：表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次；（此时可能你提交事务了，结果 mysql 宕机了，然后内存里的数据全部丢失。）

1：每次事务的提交都会引起redo日志文件写入、flush磁盘的操作，确保了事务的ACID；

2：每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。

注意事项：

当设置为0，该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。

当设置为1，该模式是最安全的，但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。

当设置为2，该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。

5.sync_binlog

该参数控制着二进制日志写入磁盘的过程。

该参数的有效值为0 、1、N：

0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。

1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。

N：每写N次操作系统缓冲就执行一次刷新操作。

将这个参数设为1以上的数值会提高数据库的性能，但同时会伴随数据丢失的风险。

二进制日志文件涉及到数据的恢复，以及想在主从之间获得最大的一致性，那么应该将该参数设置为1，但同时也会造成一定的性能损耗。

6.安全参数

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