我在代码中用mysql_query()函数插入数据时失败了,用mysql_error函数打出的错误是:Lost connection to MySQL server during query,这貌似是一个老问题了。我的语句长度不超过一百个字节,每条语句都是执行一条单一的插入,假设在某一个时刻,一个XX连接上来,就要对某个特定表连续执行六十多条数据的插入,但是经常是其中的一条执行失败。虽然我用mysql_option函数设置了自动重连,可在这个地方实际意义就不大了,因为实际场景中要求这连续的六十多条插入是一条也不允许失败才算完整。防火墙也关闭了。
时好时坏的,想了很多法子,现在实在没辙了,谁能站出来发句话啊,各位骨灰级专家...
时好时坏的,想了很多法子,现在实在没辙了,谁能站出来发句话啊,各位骨灰级专家...
试试:
加大wait_timeout的值,和max_allowed_packet 的值看看;
还有 net_buffer_length 的值;
但是在我的程序出错的时间段,日志中并没有错误记录。跟wait_timeout应该没什么关系吧,我一直有在操作,不会空闲超时的;而且:
[mysqldump]
quick
max_allowed_packet = 64M 这个应该够大了,我的语句都比较短,而且都只是一步操作;net_buffer_length = 8K 我连接的是本机的,不知道这个有没有影响。
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| table_lock_wait_timeout | 50 |
| wait_timeout | 28800 |
+----------------------------+-------+
10 rows in set (0.00 sec)
这个好像没什么问题,
在mysqld选项组里面加入
max_allowed_packet=64M
也可以试下:
在[mysqld]项下添加一个启动参数:
skip-name-resolve这个情况常常发生吗?还是偶尔..
把net_read_timeout 改成 60 试试
skip-name-resolve好像是远程连接时才有意义,我连的是本机的,不知道行不行,既然说了我就试呗