共计 2918 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章给大家分享的是有关 mysqlimport 如何排查导入报错问题的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
之前有个同事问我一个 mysqlimport 导入的问题，看起来还是蛮奇怪的。同事在客户端导入一个文件。文件大小是 2.8G，然后报错 mysqlimport: Error: 2013, Lost connection to MySQL server during query
对于这个问题我的第一感觉是一台云服务器，是不是没有配置 swap 造成的原因，因为在之前的一次迁移中，被这类问题折磨坏了，遭遇了 OOM-Killer 的问题，最后发现是 swap 没有配置导致的。
但是同事经过确认，这是一台实体机，而且查看硬件情况，配置还不错。buffer_pool_size 有 50 多 G，swap 也配置了。看来这个问题的原因初步排除了。
对于这个问题，网络上也有很多种说法。有的说是 max_allowed_packets 导致。查看当前的配置是 1G，看起来是比导入文件小了。
不过从 Oracle 中的经验来看，似乎这个说法也不是完全靠得住的，如果我导入一个 100G 的 dump，那这个参数还要配置超过 100G，好像听起来也不大合理啊。而且也没见过有环境配置一个极高的值。
为此我做了几个简单的测试。
首先找了一个测试环境,max_allowed_packets 为 30 多 M.
# mysqladmin var|grep max_all
| max_allowed_packet | 33554432
| slave_max_allowed_packet | 1073741824
锁定了一个小表.
] select count(*)from t_fund_info;
+———-+
| count(*) |
+———-+
| 1998067 |
通过查看文件大小，大概是 400 多 M.
-rw-rw—- 1 mysql mysql 482344960 Oct 13 16:01 t_fund_info.ibd
这样就可以轻松模拟测试 max_allowed_packets 的场景了。
首先导出文件。
select * from t_fund_info into outfile /tmp/t_fund_info.txt
Query OK, 1998067 rows affected (6.82 sec)
导出的文本文件有近 300M
ll t_fund_info.txt
-rw-rw-rw- 1 mysql mysql 291963062 Oct 20 22:25 t_fund_info.txt
然后使用最简单的命令来导入：
mysqlimport test /tmp/t_fund_info.txt
短暂的等待之后，成功导入。
可以看到慢日志的输出如下：
# Time: 161020 22:31:49
# User@Host: root[root] @ localhost []
# Thread_id: 4321910 Schema: test Last_errno: 0 Killed: 0
# Query_time: 92.866443 Lock_time: 0.000074 Rows_sent: 0 Rows_examined: 0 Rows_affected: 1998067 Rows_read: 0
# Bytes_sent: 68
SET timestamp=1476973909;
LOAD DATA INFILE /tmp/t_fund_info.txt INTO TABLE `t_fund_info` IGNORE 0 LINES;
原来 mysqlimport 会转换为 load data 的形式。
然后 delete,truncate,drop 重建，都可以成功导入。
是哪里测试的不到位吗，我开始审视这个问题，我们可以在测试环境中模拟这个问题，以当时出问题的数据为准。然后查看同事提供的日志和截图，发现当时使用的命令是
mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
这个表的字符集经过确认是 latin, 所以就在怀疑是不是因为字符集转换造成的。
ENGINE=InnoDB DEFAULT CHARSET=latin1
但是短暂的等待之后，还是可以成功导入。
# mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
在表 t_charextra 存在大量数据的前提下，我们继续尝试上面的方法导入。
整个导入就会分为两部分，
SET timestamp=1476975647;
DELETE FROM t_charextra
SET timestamp=1476975748;
LOAD DATA LOCAL INFILE /tmp/t_charextra.txt INTO TABLE `t_charextra` IGNORE 0 LINES;
还是能够成功导入
# mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
是哪里测试的不到位吗，现在唯一能够想到的就是两点，一是通过客户端调用，而是客户端和服务端的网络延迟较大。
配置了客户端用户，把导出的文本拷贝到客户端来复现问题。
grant select,insert,delete on test.* to testdb@10.127.133.86 identified by mysqlnew
Query OK, 0 rows affected (0.02 sec)
然后使用下面的命令来尝试客户端导入。
# mysqlimport -h 10.127.xxxx -utestdb -pmysqlnew test /U01/t_charextra.txt –local –delete –default-character=gbk
Warning: Using unique option prefix default-character instead of default-character-set is deprecated and will be removed in a future release. Please use the full name instead.
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
从日志看除了抛出一个警告外，一切都很正常，所以现在的重点就落在了网络上，这一点还是需要进一步确认，不过目前来看已经排除了不少原因，想必原因也快揭晓了。
感谢各位的阅读！关于“mysqlimport 如何排查导入报错问题”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
