干开发和运维的朋友谁没被“导数据”这件事折腾过不管是接手老项目、迁移数据库、恢复备份还是把外部系统的Excel、CSV塞进MySQL数据导入永远是绕不开的一环。很多新手一上来就只会用Navicat点点点导个小文件还行文件一大、数据一多要么慢得离谱要么直接卡死最后还得找老同事救场。其实MySQL本身提供了好几种导入方式各有各的适用场景选错了方法就是给自己挖坑。这篇文章我打算把最常用的4种导入方法一次讲透source命令、命令行重定向、LOAD DATA INFILE、图形化工具导入。我会结合自己这些年实际操作的经历把每种方法的原理、完整步骤、注意事项和踩坑记录都写清楚。不管你是刚入门的学生、写业务的后端开发还是专门管库的DBA应该都能从中找到适合自己场景的方案。1. 先搞明白为什么导入数据会有4种玩法1.1 数据导入的本质与常见坑我在带新人的时候总喜欢问一个问题导入数据到底是在做什么很多人答不上来只会说“就是执行SQL文件啊”。其实导入数据的本质是把“外部某个载体上的数据”映射到MySQL的表结构里。载体不同导入的最优方式就完全不同。最常见的载体有三种。第一种是已经写好的SQL脚本文件里面全是INSERT语句这种最适合用source或者重定向方式。第二种是文本数据文件比如CSV、TXT一行就是一条记录这种用LOAD DATA INFILE是最快的。第三种是数据根本不在文件里而是在另一个数据库实例或者另一张表里这种就得靠工具或者SQL语句跨库搬运。在这个过程中几乎每个人都会踩到的坑也有三类。第一是编码问题文件是GBK的数据库是UTF-8的导进去全是乱码这个报警率极高。第二是路径和权限问题MySQL服务端对读文件的路径有严格限制不是你想读哪就读哪。第三是SQL语法兼容性比如从5.7备份出来的SQL拿到8.0去执行偶尔会遇到字符集或者语法层面的不兼容。这三个坑在后面的每一种方法中都会以不同形式出现我后面会逐一说到。理解了这一点你就会明白所谓“4种导入方法”本质上是针对不同数据载体、不同数据规模、不同操作环境给出的最优解。没有哪一种方法是万能的关键是选对场景。1.2 四种方法横向对比与选型思路为了让大家一开始心里有数我先做一个横向对比。这张表我建议收藏以后碰到导入需求时拿出来对照一下基本就能确定用哪种方法了。导入方法数据载体典型场景执行速度操作门槛source命令SQL脚本文件手动登录MySQL后执行备份文件、迁移脚本中等低命令行重定向SQL脚本文件Shell脚本自动化导入、结合mysqldump做备份恢复中等中LOAD DATA INFILECSV、TXT等文本文件大数据量文本导入、数据仓库ETL环节极快高图形化工具SQL文件或文本文件新手操作、单次少量数据导入、可视化排查较慢极低选型思路很简单如果你手头拿到的已经是SQL文件那就用source或重定向区别只在于你是想手动执行还是放在脚本里自动执行如果你拿到的是CSV或TXT这类纯文本数据想追求极致导入速度那就用LOAD DATA INFILE如果你只是临时导个小文件而且电脑上装了图形化工具那直接用工具导入最省事不用记命令。我个人的习惯是生产环境、批量任务一律用命令行方式因为可以写进脚本、留日志、定时执行个人开发环境、数据量小的时候才用工具。下面就把这4种方法逐个拆开讲。2. source命令登录MySQL后最直接的导入姿势2.1 source命令基础用法source命令是MySQL客户端内置的一个命令不是SQL语句所以你只能在mysql命令行客户端里使用。它的作用很简单读取一个SQL脚本文件然后逐条执行文件里的SQL语句。具体操作分两步。第一步先登录到MySQL客户端指定要操作的数据库mysql -u root -p Enter password: ******登录成功后在mysql提示符下先用USE语句选中目标库然后执行source命令USE mydb; source /data/backup/mydb.sql;source后面跟的是文件的绝对路径。如果你不知道当前文件在哪也可以先执行pwd查看当前目录或者直接用source ./mydb.sql这种相对路径写法。需要注意Windows系统下路径要使用正斜杠或者双反斜杠比如source D:/data/mydb.sql或者source D:\\data\\mydb.sql直接用单个反斜杠会报错。执行过程中客户端会把每一条SQL语句的执行结果显示在屏幕上。如果执行成功会显示Query OK如果某条语句报错会直接显示错误信息并且默认情况下source命令会继续执行后面的语句不会中途停下来。这既是优点也是隐患后面我会讲到。source命令还有一个简写形式\.。比如\. /data/backup/mydb.sql效果完全一样。习惯用快捷键的人可能更快一些不过能记住source全称其实就够了。2.2 大文件导入与中断恢复的实战细节很多人用source导入大文件时最直观的感受就是“卡住了”屏幕上一堆Query OK刷刷刷地过然后半天没反应。其实不是卡住了是MySQL在刷盘、在写binlog、在维护索引这些操作都很耗时间。我建议在导入大文件之前先关掉自动提交并在导入结束后手动提交一次。虽然SQL文件里的INSERT语句本身会被MySQL隐式提交因为默认autocommitON但如果你在导入前设置了SET autocommit0那么所有操作都会在同一个事务里执行最后统一COMMIT。这样做的好处是第一减少了每次提交时的fsync次数导入速度会明显提升第二如果中途发现SQL文件有问题可以ROLLBACK回滚不会留下半个库的数据方便排查问题。具体操作是这样USE mydb; SET autocommit0; source /data/backup/mydb.sql; COMMIT;这里有一个很重要的前提条件被导入的表必须是InnoDB引擎事务才能覆盖所有操作。如果是MyISAM表autocommit设置对它没有意义这也就意味着中途失败无法回滚只能自己清理已经导入的部分数据。还有一个容易被忽略的问题character_set_client。如果SQL文件里没有显式的SET NAMES语句而文件编码和客户端默认编码不一致导入后中文就会变成乱码。稳妥的做法是在source之前先执行一条SET NAMES utf8mb4;这条命令会同时设置client、connection、results三者的字符集。如果你的文件是GBK编码就改成SET NAMES gbk。我的建议是在任何导入操作之前都先问自己一句文件是什么编码库表是什么编码这两者对不上后面全是泪。2.3 source为什么会中断中断之后怎么办source中断的原因我遇到最多的有三种。第一种是SQL语句本身有语法错误。典型的场景是从低版本MySQL备份出来的SQL文件拿到高版本执行某个写法不被兼容。或者文件是别人手工拼接的中间漏了分号。这种错误通常显示为ERROR 1064 (42000)。解决办法是先单独用文本编辑器打开文件定位到出错行数看看那附近的SQL有没有异常。第二种是权限不足报ERROR 1045 (28000)或ERROR 1142 (42000)。这种情况常见于用了一个只有DML权限的账号去执行包含CREATE TABLE、ALTER TABLE语句的SQL文件。解决思路很简单确认你用的是什么账号这个账号是否具备文件里涉及的所有操作权限没有的话找管理员开权限或者换root账号执行。第三种是超时或连接断开报ERROR 2013 (HY000): Lost connection to MySQL server during query。大文件导入耗时很长中间只要网络抖动一次连接就断了source自然也就终止了。这种问题在远程连接数据库时尤其常见。中断之后的处理方案要分情况。如果你按我上面说的在同一个事务里执行且还没有COMMIT那么连接断开一般会自动ROLLBACK数据不会残留。如果你没有开事务那就比较麻烦了因为文件前面的部分可能已经执行成功并提交了你无法判断当前库到底导入了多少数据。我自己的做法是在导入前记录一下目标表当前的行数中断后对比一下行数就能大致判断导入进度到哪了。如果是INSERT语句带主键或唯一索引还可以通过重复执行来“幂等恢复”——因为重复的数据插入会报主键冲突MySQL默认会跳过错误继续执行最终结果就是缺失的数据补齐了已存在的数据不受影响。这招在恢复备份时特别好用。3. 命令行重定向导入自动化与备份恢复的最佳搭档3.1 基本用法与关键参数命令行重定向导入的原理很简单利用Shell的输入重定向把SQL文件的内容作为标准输入喂给mysql命令去执行。它的核心形态是这样mysql -u root -p mydb /data/backup/mydb.sql这条命令会提示你输入密码然后把文件里的SQL语句全部执行一遍。必须注意mydb这个库名必须提前存在重定向命令不会帮你创建数据库。如果文件里已经包含了CREATE DATABASE和USE语句那命令行里的库名可以不写甚至可以不写库名直接执行mysql -u root -p /data/backup/all_databases.sql生产环境中使用重定向导入时我一般会带上下面几个参数mysql -u root -p \ --default-character-setutf8mb4 \ --force \ --show-warnings \ mydb /data/backup/mydb.sql--default-character-set指定客户端使用的字符集作用和source里的SET NAMES类似。--force表示即使某条SQL执行出错也继续执行后面的语句这个参数用不用取决于你的场景。如果是导入生产数据我建议不要加--force让它在第一个错误处停下来方便你快速定位问题如果是恢复一个几百MB的大备份加了--force能保证最大程度地恢复数据后面再单独排查错误。--show-warnings会在每条语句执行后显示警告信息对于定位数据截断、空值插入这类不致命但很影响数据质量的问题非常有用。如果你是在脚本里使用还有一个参数值得关注-e。它允许你直接在命令行里执行一段SQL而不用进入交互式客户端。比如你想先创建库再导入可以写成mysql -u root -p -e CREATE DATABASE IF NOT EXISTS mydb DEFAULT CHARSET utf8mb4; mysql -u root -p mydb /data/backup/mydb.sql这样两条命令放进Shell脚本里就能实现一条龙自动建库加导入。3.2 source与重定向到底有什么区别很多人在学习时会困惑source和重定向不都是执行SQL文件吗确实它们做的事情本质上是一样的都是把SQL文件里的语句逐条解析执行。但在实际使用中差异比想象中要大。对比项source命令命令行重定向执行环境必须先登录mysql客户端直接在Shell命令中执行适用场景临时手动操作、需要先交互脚本自动化、定时任务日志输出实时显示在客户端屏幕可以用Shell重定向保存到文件断点处理中断后需要手动排查进度中断后同样需要排查但便于脚本捕获是否依赖客户端登录依赖不依赖参数控制依赖登录后SET语句可以在命令行参数中灵活调整一个最直观的区别是重定向方式可以把执行日志保存下来方便事后复盘。比如mysql -u root -p mydb /data/backup/mydb.sql /data/log/import.log 21执行完之后所有输出、所有报错都会写进import.log你还可以通过grep -i error /data/log/import.log快速筛出错误信息。这在自动化部署、夜间定时任务里是刚需source命令就很难做到这一点。另外重定向方式还支持从管道中读取内容。这就带来很多玩法比如先压缩再导入避免大文件占满磁盘gzip -dc /data/backup/mydb.sql.gz | mysql -u root -p mydb也可以把远程服务器的备份直接拉过来导入中间不用落地文件ssh userremote cat /data/backup/mydb.sql | mysql -u root -p mydb这些操作在数据库迁移场景中非常实用我个人在给客户做机房迁移时经常用这种方式跨机器搬数据省去了先下载、再上传、再导入的三个步骤。3.3 用mysqldump导出再导入的完整备份恢复流程说重定向导入就绕不开它的最佳搭档mysqldump。mysqldump是MySQL自带的逻辑备份工具它导出的就是一个SQL文件正好可以用重定向方式导回来。这一对组合是所有DBA的基本功。整个操作流程是这样的。第一步在源库上执行导出mysqldump -u root -p \ --single-transaction \ --routines \ --triggers \ --events \ --default-character-setutf8mb4 \ mydb /data/backup/mydb.sql--single-transaction这个参数非常关键它会在InnoDB引擎下开启一个可重复读的事务来获取一致性快照备份过程中不影响线上业务读写。--routines、--triggers、--events分别导出存储过程、触发器、事件调度器不加这些参数的话你会丢东西。第二步把SQL文件传到目标机器上然后用重定向导入mysql -u root -p --default-character-setutf8mb4 mydb /data/backup/mydb.sql第三步检查数据是否完整。我常用的检查方法是比较行数SELECT COUNT(*) FROM mydb.users;源库执行一遍目标库执行一遍结果一致才算完事。如果表很多可以写个Shell循环把所有表都过一遍防止某个表因为中间报错被漏掉。这里还要提醒一个版本兼容问题mysqldump默认导出的SQL文件里会带/*!40101 SET ... */这样的条件注释表示仅在MySQL版本大于等于某个版本时才执行。理论上低版本导出、高版本导入问题不大反过来就可能遇到语法不兼容。比如5.7的库用高版本mysqldump导出再到8.0导入通常没问题但如果你把8.0导出的文件往5.7里灌就比较危险要仔细检查SQL文件头部的SET语句和字符集定义。4. LOAD DATA INFILE文本文件导入的提速利器4.1 不管用什么导入先搞定secure_file_privLOAD DATA INFILE和其他三种方法有个本质区别它读的不是SQL文件而是原始文本数据文件。也就是说文件里没有INSERT语句只有一行行的数据。MySQL服务端负责解析这个文本文件并把每一行数据映射到对应的表字段里。由于省去了SQL语句解析和生成的过程它的导入速度可以比逐条INSERT快10倍甚至更多是处理大数据量文本文件的不二之选。但在使用之前有一个绕不开的坎secure_file_priv参数。这个参数决定了MySQL服务端允许从哪个目录读取文件。在MySQL 5.7及之后的版本中这个参数默认是有值的而且权限控制非常严格。查看当前配置SHOW VARIABLES LIKE secure_file_priv;返回结果有三种可能NULL表示禁止导入导出LOAD DATA INFILE直接报错。空字符串表示不限制目录任何路径都可以读。某个具体路径比如/var/lib/mysql-files/表示只允许从这个目录读取文件。NULL是默认的安全配置但对导入操作来说非常不友好。解决办法是修改MySQL配置文件/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段下添加[mysqld] secure_file_priv/data/import/改完之后需要重启MySQL服务。这里有个细节很多人会忽略配置的目录必须存在而且MySQL的系统用户通常是mysql用户要有这个目录的访问权限否则重启后依然报错。用chown mysql:mysql /data/import把目录归属改掉再配chmod 750权限。4.2 LOAD DATA INFILE语法逐项拆解搞清楚权限限制之后我们来看完整的语法。假设我有一个CSV文件/data/import/users.csv内容如下1,张三,1990-01-01,北京 2,李四,1988-05-15,上海 3,王五,1995-12-20,广州目标表结构为CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(50), birthday DATE, city VARCHAR(50) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;导入命令LOAD DATA INFILE /data/import/users.csv INTO TABLE users FIELDS TERMINATED BY , ENCLOSED BY ESCAPED BY \\ LINES TERMINATED BY \n IGNORE 1 LINES (id, name, birthday, city);我逐个解释每个子句的含义这些都是实际工作中必须掌握的。FIELDS TERMINATED BY ,表示字段之间用逗号分隔。如果你的文件是Tab键分隔的就把逗号换成\t。ENCLOSED BY 表示字段值可能被双引号包裹。比如文件里有包含逗号内容的字段时通常会用引号括起来这个子句就是告诉MySQL去识别并去掉这些引号。如果文件里没有这种情况可以不写。ESCAPED BY \\指定转义字符默认就是反斜杠。这个处理的是字段值里包含特殊字符的情况比如John \Jack\ Smith。LINES TERMINATED BY \n表示每行数据以换行符结尾。这里有个特别容易踩的坑Windows环境下生成的CSV文件通常以\r\n结尾如果你不加处理直接按LINES TERMINATED BY \n导入最后的字段值里会残留一个\r字符。解决办法有两种一种是在命令行里把换行符写成\r\n另一种是导入之前用sed s/\r$//把文件转换一下。IGNORE 1 LINES表示跳过文件的第一行。这个通常用来略过CSV文件的表头行。如果文件没有表头就不写这个子句。最后的(id, name, birthday, city)是字段映射列表用来告诉MySQL文件里的列对应表的哪些字段。如果文件里的列顺序和表结构完全一致这一步可以省略。如果文件里缺了某些字段还可以在这里指定默认值比如LOAD DATA INFILE /data/import/users.csv INTO TABLE users FIELDS TERMINATED BY , IGNORE 1 LINES (id, name, birthday, city, created_at) SET created_at NOW();这个SET子句很实用可以在导入过程中自动填充一些业务字段比如创建时间、默认状态等等。4.3 实操把大量CSV数据导进MySQL理论讲完我拿一个真实场景来演示。曾经有一个运营系统的数据迁移任务用户表接近300万行源数据是CSV文件大小约800MB。如果一条条INSERT按每秒2000条算也要25分钟以上而LOAD DATA INFILE导入同样的数据我只用了1分40秒左右差距非常明显。操作流程大致是这样的。第一步把CSV文件上传到数据库服务器放到secure_file_priv允许读取的目录下。这里有一个细节需要注意LOAD DATA INFILE是服务端读取文件所以文件必须存放在数据库服务器上而不是客户端机器上。如果你是在自己的电脑上通过Navicat执行LOAD DATA必须在目标服务器上操作否则会报ERROR 13 (HY000): Cant get stat of file。如果你想从客户端本地上传文件应该使用LOAD DATA LOCAL INFILE这是另一个变体后面我会提到。第二步登录MySQL核对表结构然后执行LOAD DATA INFILE /data/import/users.csv INTO TABLE users CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES;这里我加了CHARACTER SET utf8mb4明确告诉MySQL文件本身的编码格式。如果不指定MySQL会使用数据库默认字符集去解析文件一旦文件编码和库编码不一致导入的中文就会变成一堆问号这是导入CSV时最频繁出现的问题。第三步验证数据。导入完成后MySQL会显示影响的行数和耗时。为了确认没有数据错位我会抽查几条数据比如用SELECT * FROM users ORDER BY RAND() LIMIT 5人工看看字段是否对得上。如果可能的话再用来源文件的行数和库里的行数做个对比。LOAD DATA LOCAL INFILE是LOAD DATA INFILE的变体区别在于它允许从客户端本地读取文件。这意味着你不需要把文件上传到服务器在自己电脑上就能执行。但它默认在MySQL 8.0中也是关闭的需要配置local_infileON才能使用而且连接参数里还要加上--local-infile1。从安全性角度考虑我建议在开发和测试环境用用就好生产环境还是用标准的LOAD DATA INFILE更稳妥。4.4 数据映射与编码的两个隐藏问题导入CSV表面上是执行一条命令实际操作中经常因为数据格式的问题导致各种奇怪的结果。最常见的是日期格式问题。MySQL的DATE字段要求是YYYY-MM-DD格式但很多业务系统导出的Excel转成CSV后日期格式是YYYY/MM/DD或者DD-MM-YYYY。直接导入会报错或者变成全零日期。解决方案是使用SET子句做转换比如LOAD DATA INFILE /data/import/users.csv INTO TABLE users FIELDS TERMINATED BY , (id, birthday_var, city) SET birthday STR_TO_DATE(birthday_var, %Y/%m/%d);这里先用一个用户变量birthday_var接收原始值再用STR_TO_DATE函数按照实际格式转换成标准日期。这种方法比先导进临时表再UPDATE要高效得多。还有一个隐藏问题是文本中包含换行符。正常的CSV规则是如果字段值本身包含逗号、换行符或双引号那么这个字段必须用引号包围起来。如果你的文件没有遵守这个规则LOAD DATA INFILE会把多行数据解析成错误的结果导致数据错位。遇到这种情况要么回源头修复文件生成逻辑要么用Python脚本先做一行清洗转换不建议在导入时硬扛。最后提醒一点LOAD DATA INFILE默认不解析表的结构变更不会像source执行SQL文件那样去建表。所以在导入之前要确保表已经建好字段顺序和类型都要匹配否则会出现ERROR 1265 (01000): Data truncated for column这类截断警告。这也是为什么我建议在执行时加SHOW WARNINGS来查看警告信息数据被截断但导入成功这种问题最隐蔽也最容易在后续查询时引发数据质量故障。5. 图形化工具导入适合团队协作与新手入门的方案5.1 Navicat导入向导走一遍如果你在Windows或Mac上工作Navicat应该是用得最多的MySQL图形化客户端。它的导入功能对新手非常友好核心操作只有几步。第一步连接上目标数据库选中目标表右键选择“导入向导”。Navicat会自动识别文件类型支持CSV、Excel、JSON、XML等多种格式甚至可以直接从另一个数据库连接导入。第二步选择文件并配置格式。如果导入CSV需要选择字段分隔符、文本限定符、字符集、表头行是否跳过。Navicat在导入预览界面会实时显示解析后的数据预览你可以直观地看到分列是否正常这一步能提前拦截80%的格式问题。第三步配置字段映射。左侧是文件里的列右侧是表的字段拖拽或者下拉选择对应关系即可。遇到不需要的列选择忽略即可。还可以在“高级”选项里设定导入模式追加、更新、删除等这些在同步增量数据时非常有用。第四步执行导入。它会显示实时进度条、每秒处理行数、失败记录数。导入完成后可以把失败记录导出成日志文件方便排查。Navicat的导入功能本质上就是在图形界面里调用了LOAD DATA或批量INSERT不过在细节上做得很到位。它会在导入前自动分析文件编码在导入失败时给出某一行第几列出错的具体提示这些都比黑乎乎的终端命令行友好得多。我经常给团队里不熟悉命令行的产品、运营同学推荐Navicat让他们自己处理小批量的Excel导入需求节省了不少沟通成本。5.2 MySQL Workbench的导入导出MySQL官方自带的Workbench同样具备导入功能而且是完全免费的。它的入口在菜单栏的“Server”下面有一个“Data Import/Export”功能。Workbench有个特点它更擅长处理mysqldump生成的SQL文件。你可以在界面里直接选择导入一个SQL dump文件它会自动帮你执行这些SQL语句相当于把source命令图形化了。导入时会显示执行进度和每一条SQL的状态也可以在“Advanced Options”里设置是否遇到错误时继续执行。不过说实话Workbench的CSV导入体验不如Navicat顺滑字段映射界面比较简陋遇到复杂格式的文件容易出问题。我的建议是如果你用的是官方工具主推SQL文件导入如果你经常要导入CSV或Excel还是用Navicat更省心。5.3 图形化工具的时间成本与使用建议图形化工具最大的优点是直观最大的缺点是性能。我曾经测试过同样一份100万行的数据文件Navicat导入用了大约15分钟LOAD DATA INFILE只用了一两分钟。原因是工具在导入过程中会产生大量日志、检查点、界面刷新开销而且很多工具为了兼容性会选择逐条INSERT而不是批处理。所以我的建议很明确数据量在几万行以内、临时操作用图形化工具没问题数据量上了百万行或者需要在生产环境做“准实时”导入老老实实用LOAD DATA INFILE。另外不管用什么工具导入前务必确认文件编码和表字符集一致导入后务必抽查数据完整性这两个习惯能帮你避免绝大多数“数据已经导进去了却发现到处是乱码和错位”的悲剧。6. 常见问题与排查技巧实录6.1 我见过最多的12个错误速查表为了让大家少走弯路我把这些年遇到的报错整理成一张速查表。遇到问题时先对着表自查一遍大多数问题都能当场解决。错误码或关键字可能原因解决方案ERROR 1045 (28000)账号密码错误或权限不足检查账号、授权范围ERROR 1049 (42000) Unknown database目标库不存在先CREATE DATABASEERROR 1064 (42000)SQL语法错误检查SQL文件内容、版本兼容性ERROR 1290 (HY000)触发了secure_file_priv限制调整配置文件或文件位置ERROR 13 (HY000)文件路径不可访问确认目录存在且MySQL用户有权限ERROR 3948 (42000)本地加载被禁用开启local_infile参数ERROR 2002 (HY000)无法通过socket连接MySQL检查服务是否启动、socket路径ERROR 2013 (HY000)导入过程中连接断开大文件分批次导入、调整超时参数ERROR 1265 (01000) Data truncated数据被截断类型不匹配检查字段长度与类型、查看WarningsERROR 1406 (22001)数据超过字段最大长度扩展字段长度或清洗源数据中文乱码文件编码与客户端/库字符集不一致统一字符集指定CHARACTER SET数据错位分隔符或转义符配置错误检查CSV格式使用预览功能6.2 排查思路三步走遇到导入问题不要急着搜报错信息先按下面三个步骤理清思路。第一步是确认环境和权限。MySQL服务是否启动你登录用的账号是否有目标库的读写权限如果是从远程连接网络是否通很多ERROR 2002、ERROR 1045都可以在这一步解决。特别是ERROR 2002它很常见的原因是mysql服务没起来或者socket路径不对检查一下systemctl status mysql就能定位。第二步是确认文件与编码。文件在哪个目录路径有没有特殊字符文件第一行是什么内容文件是UTF-8还是GBK这一步能解决90%的乱码问题。我习惯用一个简单的命令快速判断文件编码file -i /data/import/users.csv它会返回类似text/plain; charsetutf-8的信息一眼就知道该用什么字符集去导入。第三步是确认表结构与字段映射。源文件的列顺序和目标表的字段是否一致字段类型是否兼容有没有NOT NULL字段在文件中缺失这些检查清楚了LOAD DATA INFILE和图形化工具的报错基本都能消失。这三步走下来如果问题还没解决再把完整的报错信息和上下文整理出来去搜索效率会高很多。6.3 折腾了这么多次我最想叮嘱的事写到最后分享一点个人的心得吧。我见过太多人拿到一个导入需求第一反应就是打开Navicat一顿操作文件拖进去、点下一步、下一步、完成然后发现数据不对又回头查编码、查映射。其实在动手之前先花一分钟想清楚数据是什么格式文件多大是一次性导入还是需要定期导入这决定了你应该用哪种方法。数据量小的用工具或者source都行怎么方便怎么来。数据量上来了一定要用LOAD DATA INFILE它在性能上的优势是其他方法完全无法替代的。需要自动化的用命令行重定向加mysqldump写进定时任务里稳定又省心。记住一个底线任何导入操作在正式执行之前先确认有备份。哪怕你只是往一张临时表里导数据备份了一下也不会亏这个习惯关键时刻真的能救命。另外还有一点MySQL 8.0的默认字符集已经从utf8变成了utf8mb4如果你的数据库还停留在utf8碰到表情符号emoji或者生僻字就会报错或者丢失。新环境一律用utf8mb4这是我在迁移了好几个老项目之后的血泪教训。