由于mysql默认8小时连接无访问,就会断开.为此查了一下资料,有同种比较简单的解决方案:

mysql 8小时空闲后连接失效的解决,mysql8小时

查了一下发现应用程序和mysql数据库建立连接,如果超过8小时应用程序不去访问数据库,数据库就断掉连接
。这时再次访问就会抛出异常。

关于mysql自动断开的问题研究结果如下,

1、在自己的程序中插入定时访问数据库的方法,比如使用Timer,Quartz或者spring中简易Quartz。

2、在mysql中有相关参数设定,当数据库连接空闲一定时间后,服务器就会断开等待超时的连接:
相关参数

mysql> show variables like '%timeout%';
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 50       |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| rpl_stop_slave_timeout      | 31536000 |
| slave_net_timeout           | 3600     |
| wait_timeout                | 28800    |
+-----------------------------+----------+
12 rows in set

 

同一时间,interactive_timeout,wait_timeout 这两个参数只有一个起作用。

到底是哪个参数起作用,和用户连接时指定的连接参数相关,缺省情况下是使用wait_timeout。

我在配置文件中将wait_timeout修改后在mysql中查寻到还是不起作用,于是将这两个参数都修改了,再次查询wait_timeout的值后才显示修改后的。

2、修改参数
这两个参数的默认值是8小时(60*60*8=28800)。测试过将这两个参数改为0,系统自动将这个值设置为1。也就是说,不能将该值设置为永久。
将这2个参数设置为24小时(60*60*24=86400)。
set interactive_timeout=86400;
set wait_timeout=86400;

也可以修改my.cof,修改后重起mysql
打开/etc/my.cnf,在属性组mysqld下面添加参数如下:
[mysqld]
interactive_timeout=28800000
wait_timeout=28800000

如果一段时间内没有数据库访问则mysql自身将切断连接,之后访问java访问连接池时对数据库的数据通道早就关闭了

8小时空闲后连接失效的解决,mysql8小时
查了一下发现应用程序和mysql数据库建立连接,如果超过8小时应用程序不去访问数据库,数据…

mysql每次建立一个socket连接(connect)时,这个socket都会占用一定内存。即使你关闭(close)连接时,并不是真正的关闭,而是处于睡眠(sleep)状态。

 

  1. 增加 MySQL 的 wait_timeout 属性的值。 

当你下次再进行连接时,就可以快速启动当前处于睡眠状态的socket。但是过多的socket会占用大量的内存,为解决这个问题,mysql有个超时机制。

Mysql占用CPU过高的时候,该从哪些方面下手进行优化?
占用CPU过高,可以做如下考虑:
1)一般来讲,排除高并发的因素,还是要找到导致你CPU过高的哪几条在执行的SQL,show
processlist语句,查找负荷最重的SQL语句,优化该SQL,比如适当建立某字段的索引;
2)打开慢查询日志,将那些执行时间过长且占用资源过多的SQL拿来进行explain分析,导致CPU过高,多数是GroupBy、OrderBy排序问题所导致,然后慢慢进行优化改进。比如优化insert语句、优化group
by语句、优化order by语句、优化join语句等等;
3)考虑定时优化文件及索引;
4)定期分析表,使用optimize table;
5)优化数据库对象;
6)考虑是否是锁问题;
7)调整一些MySQL
Server参数,比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等;
8)如果数据量过大,可以考虑使用MySQL集群或者搭建高可用环境。
9)可能由于内存latch(泄露)导致数据库CPU高
10)在多用户高并发的情况下,任何系统都会hold不住的,所以,使用缓存是必须的,使用memcached或者redis缓存都可以;
11)看看tmp_table_size大小是否偏小,如果允许,适当的增大一点;
12)如果max_heap_table_size配置的过小,增大一点;
13)mysql的sql语句睡眠连接超时时间设置问题(wait_timeout)
14)使用show
processlist查看mysql连接数,看看是否超过了mysql设置的连接数()

修改 /etc/mysql/my.cnf文件,在 [mysqld] 节中设置: 
# Set a connection to wait 8hours in idle status.  wait_timeout
=86400 

你可以使用这条语句查看当前设置的超时时间长度:

下面分享一例遇到过的案例:
网站在高峰时段访问,点击页面有点卡。登陆服务器,发现机器负载有点高,并且mysql占用了很高的CPU资源,如下图:

将这2个参数设置为24小时(60*60*24=604800)即可。  set
interactive_timeout=604800;  set wait_timeout=604800; 

show global variables like ‘wait_timeout’;

图片 1

但仍然并不完美,一旦超过这个时间没有连接,仍然会报错.为此我设计了第二种方案,防止超时,以期终极解决

得到的结果如下:

MySQL负载居高不下,如果打开了慢查询日志功能,最好的办法就是针对慢查询日志里执行慢的sql语句进行优化,如果sql语句用了大量的group
by等语句,union联合查询等肯定会将mysql的占用率提高。所以就需要优化sql语句

2.定时访问数据库,在超时之内访问mysql,就可以避免mysql断开连接

+—————+——-+
| Variable_name | Value |
+—————+——-+
| wait_timeout  | 28800   |
+—————+——-+
1 row in set (0.00 sec)

除了优化sql语句外,也可以做一些配置上的优化。在mysql中运行show
proceslist;出现下面回显结果:
1.查询有大量的Copying to tmp table on disk状态
明显是由于临时表过大导致mysql将临时表写入硬盘影响了整体性能。

 

默认是28800秒,也就是8小时

Mysql中tmp_table_size的默认值仅为16MB,在当前的情况下显然是不够用的。
mysql> show variables like “%tmp%”;
+——————-+———-+
| Variable_name | Value |
+——————-+———-+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
+——————-+———-+
4 rows in set (0.00 sec)

相关文章