Mysql优化--负载解决方案

转自https://www.cnblogs.com/pengai/articles/9190979.html

在MySQL数据库连接数很多,而且大多属于活跃的状态时MySQL机器基本上负载很高,属于基本上快要死去的状态了.这时怎么办呢?

有两个办法.

第一：先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果非常大,先改成16让机器的压力下来,然后慢慢增大,适应自已的业务.

处理方法: set global innodb_thread_concurrency=16;

第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了，DB在了总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的.限制单用户连接数在500以下. 如:

set global max_user_connections=500;

(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因)

另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数

innodb_stats_on_metadata=0 set global innodb_stats_on_metadata=0;

这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也可以考虑禁用该参数)

 

解决思路

MySQL处在高负载环境下，磁盘IO读写过多，肯定会占用很多资源，必然CPU会占用过高。

 

占用CPU过高，可以做如下考虑：

1. 打开慢查询日志，查询是否是某个SQL语句占用过多资源，如果是的话，可以对SQL语句进行优化，比如优化 insert 语句、优化 group by 语句、优化 order by 语句、优化 join 语句等等；

2. 考虑索引问题；

3. 定期分析表，使用optimize table；

4. 优化数据库对象；

5. 考虑是否是锁问题；

6. 调整一些MySQL Server参数，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；

7. 如果数据量过大，可以考虑使用MySQL集群或者搭建高可用环境。

 

一般来讲，排除高并发的因素，还是要找到导致你CPU过高的哪几条在执行的SQL，可以查slowlog,也可以使用innotop等工具实时监控，将那些执行时间过长且占用资源过多的SQL拿来进行EXPLAIN分析，查看是否索引添加正常，还是SQL效率不行，导致CPU过高，多数是Group By、Order By排序问题所导致，然后慢慢进行优化改进。

 

 

第二次整理

 

参考资料：

 

http://blog.liuts.com/post/24/

 

 

同时在线访问量继续增大对于1G内存的服务器明显感觉到吃力，严重时甚至每天都会死机或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月，MySQL使用的是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的内存以得到更好的性能。安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。

 

一般的情况下，my-medium.cnf这个配制文件就能满足我们的大多需要；一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了，使用mysqladmin variables extended-status -u root -p 可以看到目前的参数，有３个配置参数是最重要的，即key_buffer_size,query_cache_size,table_cache。

 

 

一、key_buffer_size

 

key_buffer_size只对MyISAM表起作用，

 

key_buffer_size 指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点这个数字是远远不够的，通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE‘key_read%’获得）。

 

mysql> show status like '%key_read%'; +-------------------+-----------+ | Variable_name     | Value     | +-------------------+-----------+ | Key_read_requests | 656137195 | | Key_reads         | 90769     | +-------------------+-----------+ 2 rows in set (0.00 sec)

 

另外一个估计key_buffer_size的办法：把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例: 比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大。

 

 

二、query_cache_size

 

从4.0.1开始，MySQL提供了查询缓冲机制。使用查询缓冲，MySQL将SELECT语句和查询结果存放在缓冲区中，今后对于同样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最多可以提高238%的效率。

 

通过查看以下几个参数可以知道query_cache_size设置得是否合理：

 

Qcache inserts

 

Qcache hits

 

Qcache lowmem prunes

 

Qcache free blocks

 

Qcache total blocks

 

 

 

Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况,同时Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小，Qcache_hits的值不大，则表明你的查询重复率很低，这种情况下使用查询缓冲反而会影响效率，那么可以考虑不用查询缓冲。此外，在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

 

Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多

query_cache_type 指定是否使用查询缓冲

 

mysql> show status like '%Qcache%'; +-------------------------+-----------+ | Variable_name           | Value     | +-------------------------+-----------+ | Qcache_free_blocks      | 1         | | Qcache_free_memory      | 268417456 | | Qcache_hits             | 0         | | Qcache_inserts          | 0         | | Qcache_lowmem_prunes    | 0         | | Qcache_not_cached       | 2847583   | | Qcache_queries_in_cache | 0         | | Qcache_total_blocks     | 1         | +-------------------------+-----------+ 8 rows in set (0.00 sec)

 

我设置:

 

query_cache_size = 32M

 

query_cache_type= 1

 

 

 

得到如下状态值:

 

Qcache queries in cache 12737  表明目前缓存的条数

 

Qcache inserts 20649006

 

Qcache hits 79060095 　 看来重复查询率还挺高的

 

Qcache lowmem prunes 617913　有这么多次出现缓存过低的情况

 

Qcache not cached 189896 　　

 

Qcache free memory 18573912　　目前剩余缓存空间

 

Qcache free blocks 5328     这个数字似乎有点大　碎片不少

 

Qcache total blocks 30953

 

 

 

如果内存允许32M应该要往上加点

 

“Qcache_inserts”： 多少次未命中然后插入。通过“Qcache_hits”和“Qcache_inserts”两个参数我们就可以算出Query Cache 的命中率了：

 

Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )；

 

“Qcache_lowmem_prunes”： 多少条Query 因为内存不足而被清除出Query Cache。通过“Qcache_lowmem_prunes”和“Qcache_free_memory”相互结合，能够更清楚的了解到我们系统中Query Cache 的内存大小是否真的足够，是否非常频繁的出现因为内存不足而有Query 被换出

 

“Qcache_not_cached”： 因为query_cache_type 的设置或者不能被cache 的Query 的数量；

 

“Qcache_queries_in_cache”：当前Query Cache 中cache 的Query 数量；

 

“Qcache_total_blocks”：当前Query Cache 中的block 数量；

 

 

Query Cache 的限制

 

Query Cache 由于存放的都是逻辑结构的Result Set，而不是物理的数据页，所以在性能提升的同时，也会受到一些特定的限制。

 

a) 5.1.17 之前的版本不能Cache 绑定变量的Query，但是从5.1.17 版本开始，Query Cache 已经开始支持帮定变量的Query 了；

 

b) 所有子查询中的外部查询SQL 不能被Cache；

 

c) 在Procedure，Function 以及Trigger 中的Query 不能被Cache；

 

d) 包含其他很多每次执行可能得到不一样结果的函数的Query 不能被Cache。

 

鉴于上面的这些限制，在使用Query Cache 的过程中，建议通过精确设置的方式来使用，仅仅让合适的表的数据可以进入Query Cache，仅仅让某些Query 的查询结果被Cache。

 

 

与查询缓冲有关的参数还有query_cache_type、query_cache_limit、query_cache_min_res_unit。

 

1） query_cache_type 指定是否使用查询缓冲，可以设置为0、1、2，该变量是SESSION级的变量。

 

2） query_cache_limit 指定单个查询能够使用的缓冲区大小，缺省为1M。

query_cache_min_res_unit是在4.1版本以后引入的，它指定分配缓冲区空间的最小单位，缺省为4K。检查状态值Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多，这就表明查询结果都比较小，此时需要减小query_cache_min_res_unit。

 

1）查询缓存不适用于存储经常变化的数据表相关的查询（因为会失效，占内存且频繁过期）结合搜房网的大多数数据在网上的经常变化的特点。query_cache_type可以设置成2，对一些需要常用的查询 (例如城市分类表 栏目分类表的查询) 采用SELECT SQL_CACHE 前缀手工指定缓存。这样一方面可以很好的利用查询缓存，又不会让频敏更新的查询挤占查询空间

 

2）如果不启用查询缓存(query_cache_type =0) 要把query_cache_size也设置成0 否则内存也会被浪费

 

如果设置为0，那么可以说，你的缓存根本就没有用，相当于禁用了。但是这种情况下query_cache_size设置的大小系统是否要为其分配呢，这个问题有待于测试？

 

如果设置为1，将会缓存所有的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。

 

如果设置为2，则只缓存在select语句中通过SQL_CACHE指定需要缓存的查询。

 

 

三、table_cache

 

table_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache，并且opened_tables在不断增长，那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。

 

 

对于有1G内存的机器，推荐值是128－256。

 

笔者设置table_cache = 256

 

得到以下状态:

 

Open tables 256

 

Opened tables 9046

 

虽然open_tables已经等于table_cache，但是相对于服务器运行时间来说,已经运行了20天，opened_tables的值也非常低。因此，增加table_cache的值应该用处不大。如果运行了6个小时就出现上述值 那就要考虑增大table_cache。

 

 

四、Log-bin

 

如果你不需要记录二进制log 就把这个功能关掉，注意关掉以后就不能恢复出问题前的数据了，需要您手动备份，二进制日志包含所有更新数据的语句，其目的是在恢复数据库时用它来把数据尽可能恢复到最后的状态。另外，如果做同步复制( Replication )的话，也需要使用二进制日志传送修改情况。

 

log_bin指定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。MySQL会在文件名后面自动添加数字引，每次启动服务时，都会重新生成一个新的二进制文件。此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定记录的数据库；使用binlog-ignore-db可以指定不记录的数据库。注意的是：binlog-do-db和binlog-ignore-db一次只指定一个数据库，指定多个数据库需要多个语句。而且，MySQL会将所有的数据库名称改成小写，在指定数据库时必须全部使用小写名字，否则不会起作用。

 

关掉这个功能只需要在他前面加上#号

 

#log-bin

 

 

五、开启慢查询日志

 

开启慢查询日志( slow query log )

 

慢查询日志对于跟踪有问题的查询非常有用。它记录所有查过long_query_time的查询，如果需要，还可以记录不使用索引的记录。下面是一个慢查询日志的例子：

 

开启慢查询日志，需要设置参数log_slow_queries、long_query_times、log-queries-not-using-indexes。

 

log_slow_queries指定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。long_query_times指定慢查询的阈值，缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的参数，它指示记录不使用索引的查询。笔者设置long_query_time=10

 

 

六、其他一些重要参数

 

笔者设置:

 

sort_buffer_size = 1M

 

max_connections=120

 

wait_timeout =120

 

back_log=100

 

read_buffer_size = 1M

 

thread_cache=32

 

interactive_timeout=120

 

thread_concurrency = 4

 

 

 

参数说明:

 

back_log

 

要求MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求，这就起作用，然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接，你需要增加它，换句话说，这值对到来的TCP/IP连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。 Unix listen(2)系统调用的手册页应该有更多的细节。检查你的OS文档找出这个变量的最大值。试图设定back_log高于你的操作系统的限制将是无效的。

 

max_connections

 

并发连接数目最大，120 超过这个值就会自动恢复，出了问题能自动解决

 

thread_cache

 

没找到具体说明，不过设置为32后 20天才创建了400多个线程 而以前一天就创建了上千个线程 所以还是有用的

 

thread_concurrency

 

#设置为你的cpu数目x2,例如，只有一个cpu,那么thread_concurrency=2

 

#有2个cpu,那么thread_concurrency=4

 

skip-innodb

 

#去掉innodb支持

 

 

 

第三次整理

 

参考资料：

 

http://dngood.blog.51cto.com/446195/1150031

 

 

一、排查思路

 

1. 确定高负载的类型,top命令查看负载高的是CPU还是IO。

 

2. mysql 下执行查看当前的连接数与执行的sql 语句。

 

3. 检查慢查询日志，可能是慢查询引起负载高。

 

4. 检查硬件问题，是否磁盘故障问题造成的。

 

5. 检查监控平台，对比此机器不同时间的负载。

 

 

二、具体步骤：

 

1、使用top命令确定高负载的类型

 

发现mysql进程的cpu占用率相当高

进一步对mysql进程排查

161个进程，3个正在运行

 

2、show processlist查看数据库进程

 

mysql> show processlist\G;

 

*************************** 1. row ***************************

 

     Id: 1

 

   User: system user

 

   Host:

 

     db: NULL

 

Command: Connect

 

   Time: 8002

 

  State: Waiting for master to send event

 

   Info: NULL

 

3、记录慢查询

log_slow_queries = /usr/local/mysql/var/slow_queries.log   #慢查询日志路径 long_query_time = 10                  #记录SQL查询超过10s的语句 log-queries-not-using-indexes = 1           #记录没有使用索引的sql

 

 

4、查看慢查询日志

tail /usr/local/mysql/var/slow_queries.log # Time: 130305  9:48:13 # User@Host: biotherm[biotherm] @  [8.8.8.45] # Query_time: 1294.881407  Lock_time: 0.000179 Rows_sent: 4  Rows_examined: 1318033 SET timestamp=1363916893; SELECT * FROM xxx_list WHERE tid = '11xx'  AND del = 0  ORDER BY  id DESC  LIMIT 0, 4;

4个参数

Query_time: 0 Lock_time: 0 Rows_sent: 1 Rows_examined: 54

分别意思为: 查询时间 锁定时间 查询结果行数 扫描行数,主要看扫描行数多的语句,然后去数据库加上对应的索引,再优化下变态的sql 语句。

 

5、特殊情况下杀掉执行时间过长的语句

找出占用cpu时间过长的sql，在mysql 下执行如下命令： show processlist; 确定后一条sql处于Query状态，且Time时间过长，锁定它的ID，执行如下命令： kill QUERY  269815764;

注意：杀死 sql进程，可能导致数据丢失，所以执行前要衡量数据的重要性。

 

show status 命令解析：

Aborted_clients   由于客户没有正确关闭连接已经死掉,已经放弃的连接数量. Aborted_connects  尝试已经失败的MySQL服务器的连接的次数. Connections  试图连接MySQL服务器的次数. Created_tmp_tables  当执行语句时,已经被创造了的隐含临时表的数量. Delayed_insert_threads  正在使用的延迟插入处理器线程的数量. Delayed_writes  用INSERT DELAYED写入的行数. Delayed_errors  用INSERT DELAYED写入的发生某些错误(可能重复键值)的行数. Flush_commands  执行FLUSH命令的次数. Handler_delete  请求从一张表中删除行的次数. Handler_read_first  请求读入表中第一行的次数. Handler_read_key  请求数字基于键读行. Handler_read_next  请求读入基于一个键的一行的次数. Handler_read_rnd  请求读入基于一个固定位置的一行的次数. Handler_update  请求更新表中一行的次数. Handler_write  请求向表中插入一行的次数. Key_blocks_used  用于关键字缓存的块的数量. Key_read_requests 请求从缓存读入一个键值的次数. Key_reads 从磁盘物理读入一个键值的次数. Key_write_requests 请求将一个关键字块写入缓存次数. Key_writes 将一个键值块物理写入磁盘的次数. Max_used_connections 同时使用的连接的最大数目. Not_flushed_key_blocks 在键缓存中已经改变但是还没被清空到磁盘上的键块. Not_flushed_delayed_rows 在INSERT DELAY队列中等待写入的行的数量. Open_tables 打开表的数量. Open_files 打开文件的数量. Open_streams 打开流的数量(主要用于日志记载） Opened_tables 已经打开的表的数量. Questions 发往服务器的查询的数量. Slow_queries 要花超过long_query_time时间的查询数量. Threads_connected 当前打开的连接的数量. Threads_running 不在睡眠的线程数量. Uptime 服务器工作了多少秒.