MySQL命令行实战：从cmd连接到数据查询的完整教程

干这行时间久了你会发现一个有意思的现象：很多人一提到操作数据库，第一反应就是打开图形化工具点几下鼠标，一旦手上只有一台普通服务器，既没有桌面环境也装不了那些花哨的客户端，整个人就懵了。其实这才应该是常态。我在某公司做过一段时间运维兼开发支持，天天跟命令行打交道，MySQL在cmd窗口里的那套操作，说穿了就是几条命令的事，但就是这几条命令，能帮你应付绝大多数临时查数、救急恢复、脚本自动化的场景。

这篇文章不打算讲什么高深的理论，就用我实际干活时的习惯，把cmd连接MySQL和日常查询这一套完整梳理一遍。从环境准备、连接命令、排错思路，到真正的查询操作和数据导入导出，每一步都配上实操解释和踩坑经验。适合刚接触数据库的初学者，也适合那些平时依赖图形化工具、想补一补基本功的开发者。看完你至少能独立完成一件事：打开一个cmd窗口，顺利连上MySQL，然后按自己的需求把数据查出来。

1. 连接MySQL前必做的环境准备

1.1 确认MySQL服务真的在运行

在敲任何命令之前，你要先搞清楚一件事：MySQL不是光装上了就能连，它的后台服务必须先起来。Windows下MySQL以服务方式运行，服务没启动，你后面输入什么都是一句"Can't connect"。

我习惯用的第一个命令是看服务列表：

net start | findstr mysql

如果返回结果里有类似MySQL、MySQL80这样名字的服务，说明服务存在。但服务存在不代表它正在运行，你还要再看它的状态。命令里只列出了已启动的服务，所以能搜到就说明它在跑，搜不到不代表服务没装，也可能是没启动。

再进一步，直接看服务的完整状态：

sc query mysql sc query MySQL80

有人会问，服务名怎么还带个80？这取决于当初安装MySQL时选的版本。5.x版本一般叫mysql，8.x版本经常是MySQL80。我在某台服务器上就遇到过这种情况，装了两个版本的MySQL实例，服务名分别是MySQL和MySQL80，端口也错开，一个3306一个3307，如果不先确认服务名和端口，后面连库就是在瞎猜。

服务没启动的话，有两种方式拉起来。第一种是图形化操作，Win+R输入services.msc，在服务列表里找到对应名称右键启动。第二种是命令行直接操作：

net start mysql

注意这里要用管理员权限的cmd，否则会提示"发生系统错误 5，拒绝访问"。这是权限问题，不是服务本身的问题，千万不用慌。

1.2 配置环境变量，告别“不是内部或外部命令”

环境准备里最容易卡住新手的，就是输入mysql后提示：

'mysql' 不是内部或外部命令，也不是可运行的程序或批处理文件

这个报错的意思是，系统在PATH环境变量里找不到mysql.exe这个程序。MySQL安装时通常会把bin目录加入环境变量，但如果你用了绿色版、或者安装时取消了相关选项，就不会自动配好。

解决办法有两个。

第一个，每次输入完整路径。比如MySQL装在D盘的Program Files目录下：

cd D:\Program Files\MySQL\MySQL Server 8.0\bin mysql -uroot -p

第二个，配置环境变量，一劳永逸。右键"此电脑"→属性→高级系统设置→环境变量，在系统变量里找到Path，新增MySQL的bin目录路径。这样配置一次，以后任何目录下都能直接敲mysql命令。

我个人强烈建议配好环境变量，因为后面要用到的mysqldump等工具也在bin目录下，配好了不光mysql能用，这些配套命令也一并解决了。有一次我在某台新服务器上没配环境变量，临时要用mysqldump备份，只能一长串绝对路径往命令里写，看着就别扭。

1.3 最标准的连接命令：mysql命令参数拆解

环境没问题之后，终于可以敲连接命令了。最经典、也最不容易出错的写法是：

mysql -uroot -p

回车后系统提示Enter password，这时候输入你的密码就行。密码在输入时不会显示任何字符，这是正常现象，不是键盘坏了。

这里有一个很重要的细节：-uroot和-p之间没有空格。写成-u root -p当然也行，但-p和密码之间的规则容易让人踩坑。

先说结论：

mysql -uroot -p123456 mysql -uroot -p 123456

这两种写法里，第一种是密码直接跟在-p后面，表示密码为123456。第二种写法问题就大了，它表示密码为空，而123456被当成要连接的数据库名。结果就是你会看到"ERROR 1045"或者"Unknown database"之类的报错。

所以我的习惯是：只写-p，不直接带密码。这样最安全，也最不容易错。环境变量里混着明文密码、命令历史里留着密码，这都不是好习惯，尤其在公司共用的服务器上。

如果你的MySQL没有用默认端口3306，需要用-P参数指定端口，注意是大写的P：

mysql -uroot -p -P3307

连接远程数据库时，用-h指定主机地址：

mysql -uroot -p -h192.168.x.x -P3306

这些参数看着简单，组合起来就是完整的一套连接方式。后面排错时你会发现，多一个参数少一个参数，报错信息天差地别。

2. 连接不上的常见原因与排查思路

2.1 ERROR 2003：服务端连不上，先看端口和进程

连接失败时，MySQL会返回错误码。我在某公司接手一个交接不完整的系统时，最常遇到的就是这个：

ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost:3306' (10061)

这个报错的意思很直白：客户端根本没跟服务端建立起连接。至于为什么不通，原因可就多了。最常见的几种：

第一种是服务没启动，按前面说的net start把服务拉起来就行。第二种是端口不对，比如说服务监听的是3307，你连接时没加-P参数，默认连3306，自然连不上。第三种是服务监听的地址不对，MySQL配置里bind-address如果写了127.0.0.1，那就只允许本机连接，远程连肯定报错。

我排查这类问题的顺序是固定的：

tasklist | findstr mysqld

看看mysqld进程是否存在。存在，再确认端口：

netstat -ano | findstr 3306

这条命令会列出所有在3306端口上进行侦听的进程及其PID，拿到PID后跟tasklist的结果对一下，基本就能确认端口是不是被MySQL占着。如果netstat结果里空空如也，说明mysqld进程虽然存在，但它可能没有正常监听这个端口，这时候就得去翻my.ini配置文件，看看端口和bind-address到底写的什么。

还有一个大坑是防火墙。有些服务器开了系统防火墙，3306端口默认对外部请求关闭，你在本机连没问题，换了台机器就超时。临时验证是不是防火墙的问题，可以直接在服务器上关掉防火墙再试一次，如果能连了，问题就明确了。但别长期关着防火墙，正规做法是在防火墙规则里放行3306端口。

2.2 ERROR 1045：账号密码被拒绝，认准这几种情况

比连不上更让人崩溃的，是连上了却进不去：

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

这个报错说明TCP连接已经建立，但用户名或密码验证没通过。最直接的原因是密码错了，这个没什么好说的，重新回忆密码就行。

但还有一种情况比较隐蔽：密码是对的，但账号的host匹配有问题。MySQL的用户权限是分主机维度的，'root'@'localhost'只允许本机用root登录，如果你的连接请求来自192.168.x.x这个地址，那就是'root'@'192.168.x.x'这个身份，而这个身份可能根本不存在或者密码不同。

判断方法很简单，你在本机用root连接成功后执行：

SELECT user, host FROM mysql.user;

看看root到底被授权了哪些主机。如果只有localhost，那远程连接root就一定会被拒绝。解决办法是创建专门的远程账号，比如：

CREATE USER 'appuser'@'%' IDENTIFIED BY 'strong_password'; GRANT SELECT ON mydb.* TO 'appuser'@'%'; FLUSH PRIVILEGES;

'%'表示任意主机。生产环境我建议按需开权限，尽量少用'%'配root，安全风险太大。某公司有个历史项目就吃过这亏，root开放远程访问后日志里出现一堆暴力尝试，最后只能封IP加改复杂密码。

还有一类1045是密码遗忘场景，这个放到后面的速查表里详细讲。

2.3 服务名不对、端口被占用和防火墙拦截

把这几个问题单独拿出来说，是因为它们都特别容易让人绕圈子。

服务名不对：不是你安装时起的服务名，而是系统注册表中的服务键名。某些版本的安装包会把服务名规范化成MySQL80这种带版本号的格式。网上一搜教程全写的net start mysql，你照着执行却报了"服务名无效"，这时候去服务管理器里看一眼真实名称就清楚了。

端口被占用：MySQL默认3306，但有些应用安装时会顺手占掉这个端口。比如某开发环境装了多个数据库或中间件，3306被另一个服务占了，MySQL起不来，起来也监听不了。用netstat -ano | findstr 3306查到占用进程后，要么停掉那个进程，要么给MySQL改端口。

防火墙拦截：这个是线上环境的常客。本地开发从来没遇到过防火墙问题，部署到一台带安全策略的服务器上就各种连接超时。某次帮某项目组排查，应用日志里全是连接超时，最后确认就是云安全组里没加3306的入方向规则，加上就通了。这里要提醒一下，云服务器的安全组和操作系统自己的防火墙是两层，都要检查。

3. 基础查询操作：从进库到拿数据的完整链路

3.1 一步步走完查询的基本流程

连接成功之后，你就进入了一个MySQL交互式客户端环境，提示符变成mysql>。这个环境下可以执行SQL语句，以分号结尾，回车执行。

刚刚连上来时，你没有处于任何数据库下。第一步通常是看看有哪些库：

SHOW DATABASES;

输出会列出当前账号可见的数据库列表。注意output里有一个information_schema、mysql、performance_schema、sys这些是系统自带的库，不要去动它们。真正你要用的业务库，一般名字一看就能认出来。

接下来进入目标库：

USE mydb;

USE不是SQL标准语句，而是MySQL客户端的专用命令，所以不打分号也能执行，但建议保持一致加上。执行成功后提示Database changed。

进了库，想看看这个库下面有哪些表：

SHOW TABLES;

看某张表的结构：

DESC users;

DESC是DESCRIBE的简写，会返回表的字段名、类型、是否允许NULL、主键等信息。这是在命令行里了解表结构最快的方式，不用开图形化工具一条条翻。

现在到了查询的核心环节。先拿最简单的全表查询：

SELECT * FROM users;

如果表数据很多，你会看到终端像流水一样刷刷刷往上滚。这不是MySQL卡了，是数据量大导致输出刷屏。而且数据量极大时，全表查询会把所有行都查出来返回给客户端，非常消耗资源。生产环境我绝对不会一上来就SELECT *，一定会带上LIMIT：

SELECT * FROM users LIMIT 10;

LIMIT 10表示最多返回10条，先看数据长什么样，再决定后面怎么继续查。这是新手最容易忽略、老手最离不开的保命参数。

实际工作中更常见的是条件查询：

SELECT id, name, created_at FROM users WHERE status = 1 ORDER BY created_at DESC LIMIT 20;

这条语句做了三件事：筛选出status字段等于1的记录、按创建时间倒序排列、只取前20条。在命令行里写多行SQL完全没问题，只要最后用分号结束就行，MySQL客户端支持回车换行继续输入，直到遇到分号才执行。

3.2 命令行下中文乱码的根源和两种解决办法

这是所有cmd操作MySQL的人早晚要遇到的大坑。查询出来的中文全是乱码，类似"涓崕浜烘皯鍏卞拰鍥?quot;这种一眼看不懂的东西。

根源在于字符集的三层不一致。cmd窗口默认的代码页是936（GBK），MySQL服务端默认字符集可能是utf8或utf8mb4，连接层的字符集又可能是另一种。数据在服务端存储是UTF-8，传给你的时候，连接层和服务端可能协商成了别的编码，cmd再用GBK去解码，出来的自然就是一团乱麻。

解决办法有两个方向。

第一个方向，让MySQL返回GBK编码的数据。进入mysql后执行：

SET NAMES gbk;

这个命令同时设置了客户端、连接层、返回结果三方面的字符集。执行之后，MySQL返回的数据就会用GBK编码，cmd用GBK解码显示，中文就正常了。我注意到，每次新开一个cmd窗口连接MySQL，都要重新执行一次SET NAMES gbk，因为它只对当前会话生效。

第二个方向，把cmd窗口改成UTF-8编码。在连接MySQL之前，先执行：

chcp 65001

chcp是change code page的缩写，65001对应UTF-8。这样cmd就用UTF-8解码输出了，而MySQL默认返回的也是UTF-8，两边一致，中文自然正常。

这两个方案我都长期用过。说实话，方案一更顺手，因为SET NAMES gbk不影响cmd窗口里跑其他Windows命令的输出。方案二有个隐患，某些Windows版本在65001代码页下，中文输入和显示会出现奇怪的问题，字体也不好看。

另外提醒一下，在真正的SQL文件里处理数据时，导出的文件格式和内容编码问题要特别注意，建议导出时用--default-character-set=utf8mb4参数统一字符集，别让乱码问题延续到文件层面。

3.3 限制返回结果：别让一个SELECT把终端卡死

前面提到LIMIT，这里值得展开说说。在某次处理某跨平台系统的问题时，有个同事执行了一个不带LIMIT的SELECT，结果几百万行的数据直接往终端里灌，卡了十几分钟才反应过来Ctrl+C中断。这不仅浪费时间，还占用了大量数据库连接资源。

命令行下操作数据库，默认没有图形化工具那种"只显示前100行"的保护机制。SELECT * FROM table会老老实实把符合条件的全部记录都返回。除非你就是要导出全部数据，否则查询时务必带上LIMIT。

数值大小看场景。想快速看看数据结构，LIMIT 10就够。做分页查询，LIMIT 20, 10表示跳过20条取10条，对应第3页。数据分析时，LIMIT 1000也是合理的上限。判断标准很简单：这条查询是为了人眼观察，还是为了程序处理。为了人眼观察，一定要限制数量。

还有一个细节，对于超大表的统计类查询，比如COUNT()，全表扫描也可能很慢。MySQL 8.0里InnoDB引擎的COUNT()不带条件时做了优化，但带WHERE条件的统计依然可能耗时。这类操作用在命令行下，要有等待的心理准备，别一卡就想当然认为数据库出问题了。

4. 进阶实操：数据导入导出的正确姿势

4.1 备份和恢复：mysqldump vs mysql重定向

命令行下做数据备份，主角是mysqldump。它不是mysql客户端里的命令，而是一个独立的可执行程序，同样在bin目录下。很多人第一次用就在mysql>下输入mysqldump，然后报错，就是这个原因。mysqldump要在系统命令行环境下执行，先退出mysql交互环境，或者新开一个cmd窗口。

最简单的备份命令：

mysqldump -uroot -p mydb > D:\backup\mydb.sql

这条命令把mydb库的所有表结构和数据导出到D盘backup目录下的mydb.sql文件。mysqldump还有很多常用参数，我列出实际用过的几个：

mysqldump -uroot -p --databases mydb1 mydb2 > multi.sql mysqldump -uroot -p --single-transaction mydb > mydb.sql mysqldump -uroot -p --no-data mydb > schema_only.sql

--databases后面可以跟多个库名，导出时还会包含CREATE DATABASE语句。--single-transaction对InnoDB表特别重要，它利用事务机制做一致性快照，备份过程中不影响线上读写，是生产环境备份的推荐参数。--no-data只导出表结构，不带数据，适合迁移表结构时用。

恢复数据时，很多人会把导入和导出搞混。导出用>重定向，把命令输出写进文件。导入正好相反，用<重定向，把文件内容作为输入喂给命令：

mysql -uroot -p mydb < D:\backup\mydb.sql

这条命令会执行mydb.sql里的所有SQL语句，把数据恢复到mydb库。注意前提是mydb这个库已经存在，mysqldump导出时如果不带--databases参数，文件里不会自动创建数据库。

某次恢复数据时，我执行导入命令后等了很久都没动静，一查才发现，因为当时mysqldump是用--databases导出的，文件里自带CREATE DATABASE IF NOT EXISTS mydb语句，我又手动先建了一次库，结果表全部重建成功但数据因为某些权限问题没写入。后来学乖了，导入前先看一眼.sql文件开头，确认它包含哪些语句，再决定要不要自己建库。

4.2 用source命令执行SQL脚本和tee记录日志

除了重定向导入，MySQL客户端里还有一个source命令可以执行SQL文件，在mysql>环境下使用：

source D:\backup\mydb.sql;

source和重定向导入的差别在于，source是在当前会话里逐句执行文件中的SQL，你能实时看到每条语句的执行结果和报错信息，特别适合排查SQL文件里哪一行写了会报错。重定向导入则是闷头一股脑跑，有问题只报一条错误然后中断。

还有一个很实用的命令是tee，它可以记录当前会话的所有输入输出到一个文件：

tee D:\log\mysql_session.log;

开启后，你在这个会话里执行的每条SQL和返回结果都会同步写入这个日志文件。这功能在复现问题时特别好用。有一次在某项目现场排查慢查询，我开着tee把整个排查过程记录下来，回头整理成报告发给开发团队，省得靠脑子回忆。

关闭tee记录用：

notee;

需要说明的是，命令行交互环境下，这些命令的实际体验和文档描述略有出入。source命令处理大文件时，如果中间某条语句出错，默认会继续执行后续语句还是停下，取决于客户端配置。稳妥起见，大文件导入我还是优先用重定向方式，小文件或调试场景用source。

5. 高频问题排查速查表与避坑经验

5.1 错误码速查表

把多年的命令行排错经验整理成一张表，按图索骥能省不少时间：

排查的第一步永远是看错误码，不要凭感觉猜。每个错误码背后对应的是某一层的故障，定位准了再动手，效率差好几倍。

5.2 我踩过的几个坑和总结出来的习惯

第一个坑：密码参数直接暴露在命令历史里。开头讲过-p后直接跟密码的写法，虽然能用，但bad habit。因为cmd的历史记录里会留下完整命令，包括明文密码。共用机器上这是大忌。我的习惯是只写-p，手动输入密码。如果实在要自动化，可以把密码配置在.my.cnf或my.ini的客户端配置段里，设置好文件权限。

第二个坑：root用户密码忘了的紧急处理。这个场景在交接的服务器上遇到过不止一次。处理方法是跳过权限表启动MySQL服务：

先停止MySQL服务，然后在系统命令行下用以下参数启动服务：

mysqld --skip-grant-tables

这时候再开一个新的cmd窗口，不需要密码就能进入MySQL：

mysql -uroot

进去后立即修改root密码：

FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';

改完把刚才那个mysqld进程关掉，重新启动正常服务。这个方法应急可以，但要明白，跳过权限表意味着MySQL完全没有访问控制，一定不要在公网环境或生产环境随便用。

第三个坑：大查询把终端卡死的场景。前面说过LIMIT的重要性，这里再补充一个技巧。如果你已经手滑执行了一个大查询，输出正在刷屏，可以按Ctrl+C中断当前正在执行的查询。这个操作只是中止客户端当前等待的结果，不会把数据库服务搞挂。但如果查询本身已经在服务端执行很长时间，Ctrl+C未必能立刻终止服务端的执行，你还要在另一个会话里用KILL语句杀掉对应线程。

第四个习惯：操作前后都查一遍当前状态。连接后先执行SELECT VERSION();确认版本，再执行SELECT DATABASE();确认当前所在库。批量修改数据之前，先SELECT COUNT(*)备份一下数据量。这些习惯不花功夫，却能让你在出问题时迅速定位是自己操作问题还是环境问题。

5.3 提升命令行使用效率的几个小技巧

命令行操作数据库，效率差距往往来自一些小设置。

第一个技巧是快速编辑命令。mysql客户端支持上下键翻历史，也支持左右键移动光标。长SQL写错了某个字段名，不用全部重敲，可以按左右键移到出错位置直接修改。在cmd窗口里，鼠标单击右键可以粘贴剪贴板内容，省去Ctrl+V的麻烦。但如果想用Ctrl+C复制选中内容，得先在cmd标题栏右键打开属性，勾选"使用Ctrl+Shift+C/V作为复制粘贴快捷键"，默认的Ctrl+C是中断操作，这一点很多人都搞混过。

第二个技巧是SQL语句的格式化。命令行里写SQL不像图形化工具那么宽松，一个多表关联查询要是全挤在一行里，出了错根本看不清。我的习惯是把SQL拆成多行写，每个子句单独一行：

SELECT u.id, u.name, o.order_no FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.status = 1 ORDER BY u.created_at DESC LIMIT 50;

这样写的好处有两个：一是语法结构一目了然，报错时能快速定位是哪一行的问题；二是复制到脚本文件里直接就能用，不用重新排版。

第三个技巧是把常用查询存成SQL文件。比如你经常要查某张表的特定条件数据，可以把SQL写进一个query.sql文件，需要用的时候直接：

mysql -uroot -p mydb < query.sql

或者进入mysql后：

source D:\scripts\query.sql;

这样每次执行的都是同一份脚本，不会因为手误把条件写错。我在某项目上维护了一套常用查询脚本，包括查慢SQL、查当前连接数、查表大小，都存成单独的.sql文件，要用的时候一行命令就搞定。

第四个技巧是巧用status命令。在mysql>下执行status或\s，会显示当前连接的详细信息，包括用户名、主机、端口、当前字符集、服务器版本等。排查乱码问题时，status一出来就能看出连接和服务器字符集是否一致；排查连接超时时，也能看出实际连的是哪台机器的哪个端口。这比瞎猜效率高多了。

6. 场景实战：用cmd完成一次完整的查数任务

前面五章基本上把命令和原理都过了一遍，这里我用一个具体场景把它们串起来。

某天某部门同事跑来说数据库里的订单数据不对，让我帮着查一下某个时间段的订单状态分布。对方只给了一个模糊的时间范围，具体要查什么字段也没说清楚。这种临时查数任务，我一般按这个流程来。

第一步，连接数据库。新开cmd窗口，配好环境变量的情况下直接：

mysql -uroot -p

输入密码进入mysql>后，先看一眼当前时间和版本，确认连的库是对的：

SELECT NOW(), VERSION();

第二步，找到目标库和目标表。对方没明确说库名，我先SHOW DATABASES查看有哪些库，看到一个名字里带order的，进去SHOW TABLES。找到订单表后，用DESC看结构，确认时间字段和状态字段的真实名称。这一步是查数任务的灵魂，很多人直接凭记忆写字段名，报错1054才知道拼错了。

第三步，写查询SQL。结合字段结构，针对"某个时间段的订单状态分布"写出：

SELECT status, COUNT(*) AS cnt FROM orders WHERE created_at >= '2024-01-01 00:00:00' AND created_at < '2024-02-01 00:00:00' GROUP BY status;

这条SQL用GROUP BY对status分组，用COUNT统计每组数量，一下就拿到了订单状态的分布数据。为了让结果更易读，我加上ORDER BY让数量多的排前面。

第四步，确认数据范围和时间边界。查数时最容易出问题的是时间边界的理解。'2024-01-01 00:00:00'到'2024-02-01 00:00:00'是包含1月1日、不包含2月1日的，也就是整整1月份的数据。这种左闭右开的写法能避免同一笔数据落到两个时间段里的重复计数。

第五步，输出结果给同事。如果数据不多，直接复制结果就完事。如果数据量较大，或者要发给对方进一步分析，用前面说的tee功能记录，或者直接把查询结果导出到文件：

SELECT ... INTO OUTFILE 'D:\temp\order_status_202401.csv' FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n';

这个写法需要注意，INTO OUTFILE会把文件写在MySQL服务器所在的机器上，不是在你本地cmd所在的机器。如果是远程连接的服务器，文件会落在服务器上，需要另想办法拉取。本地环境就没这个问题。还有一个坑，MySQL的secure_file_priv参数如果被设置了，限定只能写到某个指定目录，路径没在允许列表里会报ERROR 1290，这时候要么把文件写到允许目录，要么临时调整参数。

查完数顺手再确认一下连接使用情况，也是我个人的习惯：

SHOW PROCESSLIST;

这条命令会列出当前MySQL上所有正在执行的连接和会话，看一眼有没有异常的长事务或慢查询，走之前把现场清理干净，不给生产环境留隐患。

这个完整的流程走下来，你会发现命令行操作数据库不复杂，但对逻辑和细节的要求比较高。和图形化工具比起来，它少了鼠标点击的便利，却多了脚本化、可复现、轻量化的优势。服务器上排查问题、写自动化任务、快速验证SQL，这套技能早晚用得上。

最后说点实在的，我个人的体会是，命令行这东西，光看不练等于白看。找一台测试环境，装上MySQL，把这里的命令挨个敲一遍，敲完基本就掌握了。踩坑也没关系，多踩几次就记住了。真正用命令行处理过几次线上查数和数据恢复之后，你会慢慢习惯这个方式，甚至会觉得比图形化工具来得更干脆。