Mysql导入大文件的处置_mysql

在从新浪云导出到本地时，经常会遇到数据库中数据量过多，导致导入本地时出现Mysql Server has gone away 的提示，并且导入不成功。这个提示表示mysql服务器已经断开连接。服务器断开连接的原音有很多，这里我们总结了几个比较主要的原因，并且给出了一些处理服务器断开问题的解决方案：

mysql服务器宕机

判断是否属于这个原因的方法很简单，执行以下命令，查看mysql的运行时长

> mysql -uroot -p -e "show global status like 'uptime';" Enter password: ****** +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime        | 1843  | +---------------+-------+

查询运行时间时，我们使用了命令 show global status ，这是mysql定义的查看本服务器从开启启动到现在的运行状态的统计。与该命令相近的还有show status ，show status –>questions是你本次连接的请求数,可以使用flush status重置。

根据show [global] status 的question，我们可以获取很多关于服 务器的信息，具体的question，我们可以查询Mysql 5.1 手册 来查询。也可以见附录。

或者查看MySQL的报错日志（linux下），看看有没有重启的信息

$ tail /var/log/mysql/error.log 130101 22:22:30 InnoDB: Initializing buffer pool, size = 256.0M 130101 22:22:30 InnoDB: Completed initialization of buffer pool 130101 22:22:30 InnoDB: highest supported file format is Barracuda. 130101 22:22:30 InnoDB: 1.1.8 started; log sequence number 63444325509 130101 22:22:30 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 130101 22:22:30 [Note]   - '127.0.0.1' resolves to '127.0.0.1'; 130101 22:22:30 [Note] Server socket created on IP: '127.0.0.1'. 130101 22:22:30 [Note] Event Scheduler: Loaded 0 events 130101 22:22:30 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.28-cll'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

WIN:

使用show variables like  '%log%'查看log文件夹，凡Value值为OFF的表示未开启服务，若要开启只需要将上的my.ini配置信息写入(my.ini为mysql安装目录下)，然后去掉前面的"#"号，再重启mysql服务。OK，现在会看到指定的日志文件已创建。相反地，若要停止mysql日志服务，只需要将my.ini中对应的配置信息去掉即可。  查看当前二进制文件状态： mysql> show master status;  

如果uptime数值很大，表明mysql服务运行了很久了。说明最近服务没有重启过。

如果日志没有相关信息，也标明mysql服务最近没有重启过，可以继续检查下面几项内容。

连接超时

如果程序使用的是长连接，则这种情况的可能性会比较大。某个长连接很久没有新的请求发起，达到了server端的timeout，被server强行关闭。此后再通过这个connection发起查询的时候，就会报错server has gone away

show global variables like '%timeout'查看session timeout。 +----------------------------+-------+ | 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)  mysql> SET SESSION wait_timeout=28800; 

方法当然是增加你的 wait-timeout值，这个参数是在my.cnf(在Windows下台下面是my.ini）中设置，我的数据库负荷稍微大一点，所以，我设置的值 为10，（这个值的单位是秒，意思是当一个数据库连接在10秒钟内没有任何操作的话，就会强行关闭，我使用的不是永久链接 （mysql_pconnect),用的是mysql_connect,关于这个wait-timeout的效果你可以在MySQL的进程列表中看到 （show processlist) ），你可以把这个wait-timeout设置成更大，比如300秒，呵呵，一般来讲300秒足够用了，其实你也可以不用设置，MySQL默认是8个小 时（28800）。情况由你的服务器和站点来定。

进程在server端被主动kill

这种情况和情况2相似，只是发起者是DBA或者其他job。发现有长时间的慢查询执行kill xxx导致。

mysql>show global status like 'com_kill'" +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Com_kill      | 0     | +---------------+-------+

表过大

当查询的结果集超过 max_allowed_packet 也会出现这样的报错。定位方法是打出相关报错的语句。

用select * into outfile 的方式导出到文件，查看文件大小是否超过 max_allowed_packet ，如果超过则需要调整参数，或者优化语句。

mysql> show global variables like 'max_allowed_packet'; +--------------------+---------+ | Variable_name      | Value   | +--------------------+---------+ | max_allowed_packet | 1048576 | +--------------------+---------+ 1 row in set (0.00 sec) 修改参数：  mysql> set global max_allowed_packet=1024*1024*16; mysql> show global variables like 'max_allowed_packet'; +--------------------+----------+ | Variable_name      | Value    | +--------------------+----------+ | max_allowed_packet | 16777216 | +--------------------+----------+ 1 row in set (0.00 sec)

附录

下面是参考官方文档及网上资料整理出来的中文详细解释(可以使用mysql> status; 看版本），不管你是初学mysql还是你是mysql专业级的dba，这都是值得看的.