Mysql配置参数说明

摘要

mysql安装以后并非默认参数就能知足生产系统的须要，须要根据业务调整不少的参数。

参数说明

硬件 16 CPU 32G Memory

# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html

[mysql] 
default-character-set = utf8mb4

[mysqld] 
character-set-client-handshake = FALSE 
character-set-server = utf8mb4 
collation-server = utf8mb4_unicode_ci 
init_connect='SET NAMES utf8mb4'

skip_host_cache
skip-name-resolve=1
###NEW####
expire_logs_days=7
back_log=300
max_connections=8000
max_connect_errors=30
#table_cache=4096
open_files_limit=10240
#thread_concurrency=64
max_allowed_packet=100000000
net_buffer_length=100000
interactive_timeout=300
wait_timeout=300
thread_cache_size=100
slow_query_log=1
long_query_time=5
sort_buffer_size=16M
read_buffer_size=16M
read_rnd_buffer_size=32M
join_buffer_size=128M
tmp_table_size=64M
table_open_cache=5000
key_buffer_size=400M
query_cache_size=128M
thread_stack=512K
innodb_buffer_pool_size=24G
#innodb_additional_mem_pool_size=20M
#innodb_file_io_threads=4
innodb_thread_concurrency=16
innodb_log_buffer_size=16M
innodb_log_file_size=512M
innodb_log_files_in_group=3
innodb_lock_wait_timeout=120
###NEW####

#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir=/opt/data/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

lower_case_table_names =1
 
# master
log-bin=mysql-bin
server-id=2 

  back_log

        该值指出在MySQL暂时中止回答新请求以前的短期内多少个请求能够被存在堆栈中。也就是说，若是MySql的链接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一链接释放资源，该堆栈的数量即back_log，若是等待链接的数量超过back_log，将不被授予链接资源。将会报：unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待链接进程时.

        back_log值不能超过TCP/IP链接的侦听队列的大小。若超过则无效，查看当前系统的TCP/IP链接的侦听队列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog目前系统为1024。对于Linux系统推荐设置为小于512的整数。

wait-timeout

MySQL默认的wait-timeout  值为8个小时，能够经过命令show variables like 'wait_timeout'查看结果值;。

设置这个值是很是有意义的，好比你的网站有大量的MySQL连接请求（每一个MySQL链接都是要内存资源开销的 ），因为你的程序的缘由有大量的链接请求空闲啥事也不干，白白占用内存资源，或者致使MySQL超过最大链接数历来没法新建链接致使“Too many connections”的错误。在设置以前你能够查看一下你的MYSQL的状态（可用show processlist)，若是常常发现MYSQL中有大量的Sleep进程，则须要 修改wait-timeout值了。

interactive_timeout：服务器关闭交互式链接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。

wait_timeout:服务器关闭非交互链接以前等待活动的秒数。在线程启动时，根据全局wait_timeout值或全局 interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的链接选项CLIENT_INTERACTIVE定义).

这两个参数必须配合使用。不然单独设置wait_timeout无效。

max_connections

指MySql的最大链接数，若是服务器的并发链接请求量比较大，建议调高此值，以增长并行链接数量，固然这创建在机器能支撑的状况下，由于若是链接数越多，介于MySql会为每一个链接提供链接缓冲区，就会开销越多的内存，因此要适当调整该值，不能盲目提升设值。能够过'conn%'通配符查看当前状态的链接数量，以定夺该值的大小。

MySQL服务器容许的最大链接数16384；

查看系统当前最大链接数：

show variables like 'max_connections';

max_user_connections

是指每一个数据库用户的最大链接

针对某一个帐号的全部客户端并行链接到MYSQL服务的最大并行链接数。简单说是指同一个帐号可以同时链接到mysql服务的最大链接数。设置为0表示不限制。

目前默认值为：0不受限制。

这儿顺便介绍下Max_used_connections:它是指从此次mysql服务启动到如今，同一时刻并行链接数的最大值。它不是指当前的链接状况，而是一个比较值。若是在过去某一个时刻，MYSQL服务同时有1000个请求链接过来，而以后再也没有出现这么大的并发请求时，则Max_used_connections=1000.请注意与show variables 里的max_user_connections的区别。默认为0表示无限大。

查看max_user_connections值

show variables like 'max_user_connections';

thread_concurrency

该值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的状况下，错误设置了thread_concurrency的值, 会致使mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工做的状况。

thread_concurrency应设为CPU核数的2倍. 好比有一个双核的CPU, 那thread_concurrency  的应该为4; 2个双核的cpu, thread_concurrency的值应为8.

好比：根据上面介绍咱们目前系统的配置，可知道为4个CPU,每一个CPU为8核，按照上面的计算规则，这儿应为:4*8*2=64

查看系统当前thread_concurrency默认配置命令：

 show variables like 'thread_concurrency';

skip-name-resolve

禁止MySQL对外部链接进行DNS解析，使用这一选项能够消除MySQL进行DNS解析的时间。但须要注意，若是开启该选项，则全部远程主机链接受权都要使用IP地址方式，不然MySQL将没法正常处理链接请求！

innodb_buffer_pool_size

主要针对InnoDB表性能影响最大的一个参数。功能与Key_buffer_size同样。InnoDB占用的内存，除innodb_buffer_pool_size用于存储页面缓存数据外，另外正常状况下还有大约8%的开销，主要用在每一个缓存页帧的描述、adaptive hash等数据结构，若是不是安全关闭，启动时还要恢复的话，还要另开大约12%的内存用于恢复，二者相加就有差很少21%的开销。假设：12G的innodb_buffer_pool_size，最多的时候InnoDB就可能占用到14.5G的内存。若系统只有16G，并且只运行MySQL，且MySQL只用InnoDB，

那么为MySQL开12G，是最大限度地利用内存了。

另外InnoDB和 MyISAM 存储引擎不一样， MyISAM 的 key_buffer_size 只能缓存索引键，而 innodb_buffer_pool_size 却能够缓存数据块和索引键。适当的增长这个参数的大小，能够有效的减小 InnoDB 类型的表的磁盘 I/O 。

当咱们操做一个 InnoDB 表的时候，返回的全部数据或者去数据过程当中用到的任何一个索引块，都会在这个内存区域中走一遭。

能够经过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。值能够用如下命令查得：show status like 'Innodb_buffer_pool_read%';

innodb_log_buffer_size 

这是InnoDB存储引擎的事务日志所使用的缓冲区。相似于Binlog Buffer，InnoDB在写事务日志的时候，为了提升性能，也是先将信息写入Innofb Log Buffer中，当知足innodb_flush_log_trx_commit参数所设置的相应条件(或者日志缓冲区写满)以后，才会将日志写到文件 (或者同步到磁盘)中。能够经过innodb_log_buffer_size 参数设置其可使用的最大内存空间。

InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲容许事务运行时不须要将日志保存入磁盘而只到事务被提交(commit)。 所以，若是有大的事务处理，设置大的日志缓冲能够减小磁盘I/O。 在 my.cnf中以数字格式设置。

默认是8MB，系的如频繁的系统可适当增大至4MB～8MB。固然如上面介绍所说，这个参数实际上还和另外的flush参数相关。通常来讲不建议超过32MB

注：innodb_flush_log_trx_commit参数对InnoDB Log的写入性能有很是关键的影响,默认值为1。该参数能够设置为0，1，2，解释以下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操做，可是每一个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操做;

1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步;

2：事务提交会触发log buffer到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操做。

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

query_cache_size

query_cache_size: 主要用来缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，因此仅仅只能针对select语句。当咱们打开了 Query Cache功能，MySQL在接受到一条select语句的请求后，若是该语句知足Query Cache的要求(未显式说明不容许使用Query Cache，或者已经显式申明须要使用Query Cache)，MySQL会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，而后到Query Cache中直接查找是否已经缓存。也就是说，若是已经在缓存中，该select请求就会直接将数据返回，从而省略了后面全部的步骤(如SQL语句的解析，优化器优化以及向存储引擎请求数据等)，极大的提升性能。根据MySQL用户手册，使用查询缓冲最多能够达到238%的效率。

固然，Query Cache也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会致使全部引用了该表的select语句在Query Cache中的缓存数据失效。因此，当咱们的数据变化很是频繁的状况下，使用Query Cache可能会得不偿失

Query Cache的使用须要多个参数配合，其中最为关键的是query_cache_size和query_cache_type，前者设置用于缓存 ResultSet的内存大小，后者设置在何场景下使用Query Cache。在以往的经验来看，若是不是用来缓存基本不变的数据的MySQL数据库，query_cache_size通常256MB是一个比较合适的大小。固然，这能够经过计算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。 query_cache_type能够设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示彻底不使用query cache，除显式要求不使用query cache(使用sql_no_cache)以外的全部的select都使用query cache，只有显示要求才使用query cache(使用sql_cache)。若是Qcache_lowmem_prunes的值很是大，则代表常常出现缓冲. 若是Qcache_hits的值也很是大，则代表查询缓冲使用很是频繁，此时须要增长缓冲大小；

根据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整，通常不建议太大，256MB可能已经差很少了，大型的配置型静态数据可适当调大.

能够经过命令：show status like 'Qcache_%';查看目前系统Query catch使用大小

| Qcache_hits             | 1892463  |

| Qcache_inserts          | 35627  

命中率98.17%=1892463/(1892463 +35627 )*100

局部缓存

除了全局缓冲，MySql还会为每一个链接发放链接缓冲。个链接到MySQL服务器的线程都须要有本身的缓冲。大概须要马上分配256K，甚至在线程空闲时，它们使用默认的线程堆栈，网络缓存等。事务开始以后，则须要增长更多的空间。运行较小的查询可能仅给指定的线程增长少许的内存消耗，然而若是对数据表作复杂的操做例如扫描、排序或者须要临时表，则需分配大约read_buffer_size，

sort_buffer_size，read_rnd_buffer_size，tmp_table_size 大小的内存空间. 不过它们只是在须要的时候才分配，而且在那些操做作完以后就释放了。有的是马上分配成单独的组块。tmp_table_size 可能高达MySQL所能分配给这个操做的最大内存空间了

。注意，这里须要考虑的不仅有一点——可能会分配多个同一种类型的缓存，例如用来处理子查询。一些特殊的查询的内存使用量可能更大——若是在MyISAM表上作成批的插入

时须要分配 bulk_insert_buffer_size 大小的内存；执行 ALTER TABLE， OPTIMIZE TABLE， REPAIR TABLE 命令时须要分配 myisam_sort_buffer_size 大小的内存。

read_buffer_size

read_buffer_size 是MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一

缓冲区的大小。若是对表的顺序扫描请求很是频繁，而且你认为频繁扫描进行得太慢，能够经过增长该变量值以及内存缓冲区大小提升其性能.

read_rnd_buffer_size

read_rnd_buffer_size 是MySql的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以免磁盘搜索，提升查询速度，若是须要排序大量数据，可适当调高该值。但MySql会为每一个客户链接发放该缓冲空间，因此应尽可能适当设置该值，以免内存开销过大。

tmp_table_size

 tmp_table_size是MySql的heap （堆积）表缓冲大小。全部联合在一个DML指令内完成，而且大多数联合甚至能够不用临时表便可以完成。大多数临时表是基于内

存的(HEAP)表。具备大的记录长度的临时表 (全部列的长度的和)或包含BLOB列的表存储在硬盘上。若是某个内部heap（堆积）表大小超过tmp_table_size，MySQL能够根据须要自动将内存中的heap表改成基于硬盘的MyISAM表。还能够经过设置tmp_table_size选项来增长临时表的大小。也就是说，若是调高该值，MySql同时将增长heap表的大小，可达到提升联接查询速度的效果。

thread_cache_size

默认的thread_cache_size=8，可是看到好多配置的样例里的值通常是32，64，甚至是128，感受这个参数对优化应该有帮助，因而查了下：
根据调查发现以上服务器线程缓存thread_cache_size没有进行设置，或者设置太小,这个值表示能够从新利用保存在缓存中线程的数量,当断开链接时若是缓存中还有空间,那么客户端的线程将被放到缓存中,若是线程从新被请求，那么请求将从缓存中读取,若是缓存中是空的或者是新的请求，那么这个线程将被从新建立,若是有不少新的线程，增长这个值能够改善系统性能.经过比较 Connections 和 Threads_created 状态的变量，能够看到这个变量的做用。(–>表示要调整的值)   根据物理内存设置规则以下：
1G —> 8
2G —> 16
3G —> 32     >3G —> 64

  mysql> show status like 'thread%';
+——————-+——-+
| Variable_name     | Value |
+——————-+——-+
| Threads_cached    | 0     |  <—当前被缓存的空闲线程的数量
| Threads_connected | 1     |  <—正在使用（处于链接状态）的线程
| Threads_created   | 1498  |  <—服务启动以来，建立了多少个线程
| Threads_running   | 1     |  <—正在忙的线程（正在查询数据，传输数据等等操做）
+——————-+——-+

查看开机起来数据库被链接了多少次？

mysql> show status like '%connection%';
+———————-+——-+
| Variable_name        | Value |
+———————-+——-+
| Connections          | 1504  |          –>服务启动以来，历史链接数
| Max_used_connections | 2     |
+———————-+——-+

经过链接线程池的命中率来判断设置值是否合适？命中率超过90%以上,设定合理。

 (Connections -  Threads_created) / Connections * 100 %

参考

http://www.javashuo.com/article/p-yjnjtfee-k.html