mysql性能优化之参数配置.docx

mysql性能优化之参数配置.docx

《mysql性能优化之参数配置.docx》由会员分享，可在线阅读，更多相关《mysql性能优化之参数配置.docx（16页珍藏版）》请在冰豆网上搜索。

mysql性能优化之参数配置

1、目的：

通过根据服务器目前状况，修改Mysql的系统参数，达到合理利用服务器现有资源，最大合理的提高MySQL性能。

2、服务器参数：

32G内存、4个CPU,每个CPU 8核。

3、MySQL目前安装状况。

  MySQL目前安装，用的是MySQL默认的最大支持配置。

拷贝的是my-f.编码已修改为UTF-8.具体修改及安装MySQL,可以参考<>帮助文档。

4、修改MySQL配置

打开MySQL配置文件f

4.1 MySQL非缓存参数变量介绍及修改

4.1.1修改back_log参数值:

由默认的50修改为500.（每个连接256kb,占用：

125M）

 back_log=500

 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的整数。

查看mysql 当前系统默认back_log值，命令：

show variables like 'back_log'; 

4.1.2修改wait_timeout参数值，由默认的8小时，修改为30分钟。

（本次不用）

 wait_timeout=1800（单位为妙）

 interactive_timeout=1800

我对wait-timeout这个参数的理解：

MySQL客户端的数据库连接闲置最大时间值。

说得比较通俗一点，就是当你的MySQL连接闲置超过一定时间后将会被强行关闭。

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无效

4.1.3修改max_connections参数值，由默认的151，修改为3000（750M）。

   max_connections=3000

max_connections是指MySql的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多，介于MySql会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。

可以通过'conn%'通配符查看当前状态的连接数量，以定夺该值的大小。

MySQL服务器允许的最大连接数16384；

查看系统当前设置的最大连接数：

show variables like 'max_connections';

4.1.4修改max_user_connections值，由默认的0，修改为800

   max_user_connections=800

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';

4.1.5修改thread_concurrency值，由目前默认的8，修改为64

 thread_concurrency=64

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';

4.1.6添加skip-name-resolve，默认被注释掉，没有该参数。

skip-name-resolve

skip-name-resolve：

禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。

但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！

4.1.7 skip-networking，默认被注释掉。

没有该参数。

（本次无用）

 skip-networking建议被注释掉，不要开启

开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！

否则将无法正常连接！

4.1.8  default-storage-engine（设置MySQL的默认存储引擎）

default-storage-engine= InnoDB（设置InnoDB类型，另外还可以设置MyISAM类型）

设置创建数据库及表默认存储类型

show table status like ‘tablename’显示表的当前存储状态值

查看MySQL有哪些存储状态及默认存储状态

 show engines;

创建表并指定存储类型

CREATE TABLE mytable （id int, title char（20）） ENGINE = INNODB;

修改表存储类型：

  Alter table tableName engine =engineName

备注：

设置完后把以下几个开启：

# Uncomment the following if you are using InnoDB tables

innodb_data_home_dir = /var/lib/mysql

#innodb_data_file_path = ibdata1:

1024M;ibdata2:

10M:

autoextend（要注释掉，否则会创建一个新的把原来的替换的。

）

innodb_log_group_home_dir = /var/lib/mysql

# You can set .._buffer_pool_size up to 50 - 80 %

# of RAM but beware of setting memory usage too high

innodb_buffer_pool_size = 1000M

innodb_additional_mem_pool_size = 20M

# Set .._log_file_size to 25 % of buffer pool size

innodb_log_file_size = 500M

innodb_log_buffer_size = 20M

innodb_flush_log_at_trx_commit = 0

innodb_lock_wait_timeout = 50

设置完后一定记得把MySQL安装目录地址（我们目前是默认安装所以地址/var/lib/mysql/）下的ib_logfile0和ib_logfile1删除掉。

否则重启MySQL起动失败。

4.2 MySQL缓存变量介绍及修改

数据库属于IO密集型的应用程序，其主职责就是数据的管理及存储工作。

而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个 IO是在毫秒级别，二者相差3个数量级。

所以，要优化数据库，首先第一步需要优化的就是IO，尽可能将磁盘IO转化为内存IO。

本文先从MySQL数据库 IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化

4.2.1全局缓存

启动MySQL时就要分配并且总是存在的全局缓存。

目前有：

key_buffer_size（默认值：

402653184,即384M）、

innodb_buffer_pool_size（默认值：

134217728即：

128M）、

innodb_additional_mem_pool_size（默认值：

8388608即：

8M）、

innodb_log_buffer_size（默认值：

8388608即：

8M）、

query_cache_size（6默认值：

16M，之前的版本为0）。

这些变量值都可以通过命令如：

show variables like '变量名';查看到。

4.2.1.1：

key_buffer_size,本系统目前为384M,可修改为400M

    key_buffer_size=400M

key_buffer_size是用于索引块的缓冲区大小，增加它可得到更好处理的索引（对所有读和多重写），对MyISAM（MySQL表存储的一种类型，可以XX等查看详情）表性能影响最大的一个参数。

如果你使它太大，系统将开始换页并且真的变慢了。

严格说是它决定了数据库索引处理的速度，尤其是索引读的速度。

对于内存在4GB左右的服务器该参数可设置为256M或384M.

怎么才能知道key_buffer_size的设置是否合理呢，一般可以检查状态值Key_read_requests和Key_reads   ，比例key_reads / key_read_requests应该尽可能的低，比如1:

100，1:

1000 ，1:

10000。

其值可以用以下命令查得：

show status like 'key_read%';

比如查看系统当前key_read和key_read_request值为：

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

| Variable_name     | Value |

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

| Key_read_requests | 28535 |

| Key_reads         | 269   |

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

可知道有28535个请求，有269个请求在内存中没有找到直接从硬盘读取索引.

未命中缓存的概率为：

0.94%=269/28535*100%.  一般未命中概率在0.1之下比较好。

目前已远远大于0.1，证明效果不好。

若命中率在0.01以下，则建议适当的减小key_buffer_size值。

4.2.1.2：

innodb_buffer_pool_size（默认128M）

innodb_buffer_pool_size=1024M（1G）

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_buffer_pool_read_requests      | 1283826 |

| Innodb_buffer_pool_reads              | 519     |

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

其命中率99.959%=（1283826-519）/1283826*100%  命中率越高越好。

4.2.1.3：

innodb_additional_mem_pool_size（默认8M）

  innodb_additional_mem_pool_size=20M

innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。

这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL会记录Warning信息到数据库的error log中，这时候你就知道该调整这个参数大小了。

查看当前系统mysql的error日志  cat  /var/lib/mysql/机器名.error 发现有很多waring警告。

所以要调大为20M.

根据MySQL手册，对于2G内存的机器，推荐值是20M；32G内存的为 100M

4.2.1.4：

innodb_log_buffer_size（默认8M）

innodb_log_buffer_size=20M

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。

 在 f中以数字格式设置。

默认是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。

4.5.1.5：

query_cache_size（默认32M）

query_cache_size=40M

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

4.2.2局部缓存

除了全局缓冲，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 大小的内存；