企业官网建设流程全解析

上周帮一位朋友处理线上订单库的迁移，我原本打算直接用图形客户端把数据导出来，结果一张两千多万行的表跑了快二十分钟都没结束，连接的测试环境都开始超时了。我临时换了个思路，打开服务器终端，用 mysqldump 把整个库打成压缩包，前后三分钟导出完毕，后续在新库恢复也只花了几分钟。这件事让我又一次确信：MySQL 命令行导出数据库，是开发和运维最该尽早掌握的基础功，也是关键时刻最救命的保底方案。这篇文章不打算讲太泛的理论，直接围绕“命令行导出数据库”这个动作，把工具选型、命令参数、生产环境实操和常见坑一次讲透。适合正在学 mysqldump 的新手、被备份迁移折腾过的后端或运维，以及所有在 Windows 和 Linux 上都踩过导出问题的同学。

1. 动手之前先想清楚：命令行导出的四种典型场景

1.1 导出不等于备份：先明确这次导出的目标

很多人一上来就敲mysqldump -u root -p database > backup.sql，这没错，但容易忽略一个关键问题：你这次导出，到底是为了什么？

我习惯把导出目标拆成四类场景，因为不同场景对应的命令参数组合差别很大：

• 全量备份留档：目的就是出问题能恢复，导出文件要完整、要可重建，通常会加上事务一致性参数，压缩后按日期留档。
• 数据迁移：把数据从 A 机器搬到 B 机器，除了表和数据，经常还要带上存储过程、触发器、事件，甚至要考虑源库和目标库版本兼容性。
• 只导结构：比如开发环境要同步生产库的表结构，但不需要数据，那就用--no-data，速度快、文件小。
• 业务抽数：给数据分析、测试联调提供部分数据，比如只要某张表某个时间段的数据，这时候就需要--where条件。

命令行导出的本质，是把 MySQL 里的表结构和数据行转换成以CREATE TABLE和INSERT语句为主的 SQL 脚本文件。这个文件的特征决定了它适合备份、迁移，也适合跨平台传递。但你要是不先想清楚用途，很容易出现“命令跑成功了，恢复时候才发现少带了触发器”这种尴尬。

1.2 为什么选 mysqldump，而不是图形客户端

每次提到命令行导出，总有人问：Navicat 不是能导出吗？甚至有人用 Workbench 的导出向导，为什么还要费劲记命令行参数？

我承认图形工具在可视化上有优势，但在真实生产环境里，它们的短板非常明显：

所以我的判断很简单：如果你的库小，用什么都行；但只要你做自动化、定时备份、或者要在无图形界面的服务器上操作，mysqldump 就是绕不开的选择。命令行导出数据库这句话本身，其实就是“用 shell 调用 mysqldump 生成 SQL 文件”这件事。

1.3 出发前的环境自查清单

命令行工具本身很成熟，但机器环境千奇百怪，我每次导出前都会花几分钟做一遍自查，省得命令报错了再去查半天：

• 确认版本：执行mysql --version，同时登录到 MySQL 里执行SELECT VERSION();。版本信息决定了你该用哪些参数，比如 8.0 的--set-gtid-purged行为就和 5.7 不完全一样。
• 确认字符集：执行SHOW VARIABLES LIKE 'character_set%';。导出前明确数据库默认字符集，后面加上--default-character-set=utf8mb4，能避免很多中文乱码问题。
• 确认权限：导出所有库需要全局权限，导出单库需要该库的 SELECT、SHOW VIEW、TRIGGER 等权限；如果使用--single-transaction，还需要 PROCESS 权限。建议执行SHOW GRANTS FOR 'backup'@'%';看清楚。
• 确认磁盘空间：执行df -h，再看下导出目录剩余空间。导出一个 50GB 的库，压缩后往往也要 5GB 以上，空间不够会直接中断，而且这种中断有时不报错，只是文件不完整。
• 确认不是跑在 mysql 交互终端里：新手最容易犯的错——在mysql>提示符后面敲mysqldump。mysqldump是独立的 shell 程序，不是 SQL 语句。先输入exit退出客户端，再回到系统 shell 执行导出命令。

2. mysqldump 核心命令拆解：从全库导出到条件导出

2.1 全库导出与单库导出：一份命令清单

最基本的导出命令值得先写清楚，因为它包含一个特别容易混淆的细节：带不带上--databases，导出的 SQL 文件内容是有区别的。

# 导出所有库 mysqldump -uroot -p --all-databases > /backup/all.sql # 导出多个指定的库 mysqldump -uroot -p --databases db1 db2 > /backup/dbs.sql # 导出单个库（不带 --databases） mysqldump -uroot -p db1 > /backup/db1.sql # 导出单个库（带上 --databases） mysqldump -uroot -p --databases db1 > /backup/db1.sql

如果目标是想在另一台机器上完整恢复一个库，我推荐写--databases db1。这样生成的 SQL 文件里会包含CREATE DATABASE IF NOT EXISTS db1和USE db1语句，导入的时候会自动建库并进入该库，你不用手动先去建一个空库。反过来，如果你只是想把某些表导入到已有的库中，就别加--databases，否则目标库的表会被覆盖或产生混乱。

另外，默认情况下mysqldump输出到标准输出，所以我们用>重定向到文件。在 Linux 下这没什么问题，在 Windows 的 cmd 或 PowerShell 下，可能会遇到编码转换问题，这时候建议改用--result-file=/绝对路径/文件.sql参数，让 mysqldump 自己写文件，绕开系统重定向的坑。

2.2 单表导出与条件导出：抽数场景的关键

如果只需要导出某几张表，而不是整个库，命令更简单：

# 导出单张表 mysqldump -uroot -p db1 orders > /backup/orders.sql # 导出多张表 mysqldump -uroot -p db1 orders order_items > /backup/orders_part.sql

真正实用的是按条件导出，这也是“命令行导出数据库”里最能提升效率的点。举个例子，你想导出 orders 表里 2025 年 1 月之后的订单：

mysqldump -uroot -p db1 orders --where="order_time >= '2025-01-01 00:00:00'" > /backup/orders_recent.sql

这里有个 shell 引号细节：最外层我用双引号，SQL 内部的字符串值用单引号。如果你反过来写，外层单引号内部又套单引号，很容易把 SQL 拆得七零八落。命令执行后你可以直接编辑 SQL 文件，或先head -n 50 file.sql看看内容是否符合预期。

遇到超大表时，我还会用--where做分片导出：比如--where="id BETWEEN 1 AND 1000000"导第一部分，再--where="id BETWEEN 1000001 AND 2000000"导第二部分。每片文件小、导得快，某一片失败只需重导该片，不用整库推倒重来。这个技巧在做数仓抽数和线上大表迁移时非常实用。

2.3 容易被忽略的元数据：存储过程、触发器、事件

只导表结构和数据，往往不够。如果库里有存储过程、函数、触发器、定时事件，默认情况下 mysqldump 不会把全部内容带上。

• --routines（可简写为-R）：导出存储过程和函数。
• --triggers：导出触发器。这个参数在 MySQL 8.0 中默认是开启的，但为了明确，我还是会在备份脚本里显式写出来。
• --events（可简写为-E）：导出计划事件。

一个典型的完整备份命令是：

mysqldump -uroot -p --databases app_db --routines --triggers --events > /backup/app_db_full.sql

很多人迁移后发现，数据对得上，但存储过程全部丢失，就是因为没加--routines。表结构、数据、存储过程、触发器、事件，这五块合在一起才能算一个“完整的库”。

2.4 一致性参数详解：--single-transaction 与锁表的选择

这是命令行导出里最需要理解的一对参数，也是我最常被问到的部分。

如果你的表都是 InnoDB，并且业务不能停，那么务必加上：

--single-transaction

它的原理是：在导出开始时开启一个事务，利用 InnoDB 的可重复读隔离级别，读取一个一致性快照。也就是说，导出过程中业务可以继续写数据，导出的内容仍然是启动那一刻的一致性状态。这个参数对线上库特别友好。

但注意，--single-transaction有一个前提条件：导出期间不能有人执行 DDL 语句（比如ALTER TABLE、DROP TABLE），否则可能报错Table definition has changed或直接导致导出失败。而且这个参数需要额外的 PROCESS 权限，后面权限部分会细说。

如果你的表里有 MyISAM，情况就不一样了。MyISAM 不支持事务，只能用锁表的方式来保证一致性：

--lock-tables

这个参数会在导出时锁定当前库的所有表，导出的内容是一致的，但业务写入会被阻塞，相当于短暂的只读窗口。如果多个库一起导出，还需要考虑使用--lock-all-tables，否则不同库之间的一致性无法保证。

还有一个常用参数--master-data=2（MySQL 8.0 中推荐用--source-data=2），它会在导出文件里以注释形式记录当时的 binlog 文件名和位置。做从库搭建或备份恢复到复制拓扑时很有用，但如果你只是一次普通的数据迁移，不需要搭建主从，我觉得不一定要加。参数不是堆得越多越好，关键是贴合场景。

2.5 二进制字段与字符集：两个细节决定能否还原

导出数据时，最坑的往往不是主流字段，而是那些平时不起眼的 BLOB 类型数据和字符集不一致。

处理二进制字段，我会建议显式加一个参数：

--hex-blob

加上它之后，BINARY、VARBINARY、BLOB、BIT等类型的值会用十六进制形式写入 SQL 文件，避免在导入时遇到非 UTF-8 字节、转义字符、换行符等莫名其妙的问题。这个参数没有明显的副作用，我在生产备份命令里会默认带上。

字符集方面，核心参数是这个：

--default-character-set=utf8mb4

utf8mb4 才是真正完整的 UTF-8 实现，能支持 Emoji 和生僻字，而 MySQL 里旧的utf8（即 utf8mb3）并不完整。导出端指定后，生成的 SQL 文件里会写明字符集；导入端用同样参数执行，中文就不会变成问号。如果你在 Windows 环境下，还要留意 shell 重定向本身的编码转换，这时候使用--result-file比>更稳妥。

3. 实操记录：一个生产库从导出到恢复的完整流程

3.1 场景设定与命令设计：参数不是越多越好

假设有个电商订单库 app_db，总大小约 30GB，核心表 orders 有 1200 万行，包含几个 BLOB 字段，存储引擎是 InnoDB。现在要把数据迁移到另一台新服务器，新服务器的 MySQL 版本略有不同，整个导出过程不希望长时间锁表，业务需要继续运行。

我选择的命令长这样：

mysqldump -u backup_user -p \ --single-transaction \ --quick \ --set-gtid-purged=OFF \ --routines \ --triggers \ --events \ --hex-blob \ --default-character-set=utf8mb4 \ --databases app_db \ 2>/tmp/backup_err.log | gzip > /data/backup/app_db_$(date +%F).sql.gz

逐段解释我为什么这么写：

• --single-transaction：保证导出的是某个时间点的一致性快照，且不锁业务写入。
• --quick：让 mysqldump 边读取边写出，而不是把整表数据加载到内存再输出，大表导出时的内存占用会小很多，实测下来对 1200 万行的表效果明显。
• --set-gtid-purged=OFF：MySQL 8.0 默认会在导出文件里写入 GTID_PURGED 信息。如果你后续导入的实例已经运行过其他事务，GTID 信息可能导致GTID_PURGED cannot be changed之类的报错。普通迁移场景下，我习惯显式关掉它。
• --routines --triggers --events：保证存储过程、触发器、定时事件一并在备份里。
• --hex-blob：BLOB 字段按十六进制导出，避免导入乱码。
• --default-character-set=utf8mb4：统一字符集。
• 2>/tmp/backup_err.log：关键细节。mysqldump 的运行提示和警告走的是标准错误输出，如果直接2>&1把它混进标准输出，再通过管道传给 gzip，那些警告文本就会混进 SQL 头尾，导入时可能报语法错误。所以我把 stderr 单独存成日志文件。
• | gzip：边导出边压缩，30GB 的库压缩后通常能到 3~5GB，节省磁盘和网络传输时间。

3.2 执行导出与输出解读：别忽略 stderr

执行完上面的命令后，我一般先看日志文件的内容：

cat /tmp/backup_err.log

正常情况下会看到类似这样的提示：

mysqldump: [Warning] Using a password on the command line interface can be insecure. mysqldump: [INFO] Connecting to MySQL server... Dump completed in 213.8 seconds

第一条 Warning 是提示密码暴露在命令行里，不用慌，后面权限部分我会说明更好的做法。最后一行Dump completed意味着导出过程完整结束。

接着用 gzip 检查压缩包是否完整：

gzip -t /data/backup/app_db_2025-06-01.sql.gz && echo "压缩包完整性检查通过"

如果没走压缩，直接看 SQL 文件最后几行有没有：

tail -n 5 /backup/app_db.sql

正常结尾会包含一句-- Dump completed on 2025-06-01 02:00:00。如果文件结尾不是这条注释，而是突然中断的 INSERT 语句，说明导出过程中发生了磁盘满、断网、连接中断等意外，这份备份不能信任。

3.3 恢复验证：导入新库并核对数据量

备份文件最终要能在目标环境恢复。我的恢复命令是：

gunzip -c /data/backup/app_db_2025-06-01.sql.gz | mysql -u root -p -h 10.0.0.8 --default-character-set=utf8mb4

因为备份命令里用了--databases app_db，SQL 文件自带CREATE DATABASE和USE，所以不需要手动先建库，直接导入即可。

导入完成后，我至少会做三样核对：

1. 统计关键表的行数：

mysql -uroot -p -e "SELECT COUNT(*) FROM app_db.orders;"

2. 对比导出前记录的行数参照值。导出前可以先用 information_schema 查一下大致的行数，或者更大一点的表用SELECT MAX(id)做个锚点，恢复后对比锚点是否一致。

3. 随机抽查几条包含 BLOB 或中文内容的记录，确认内容没有乱码和丢失。

只有在验证通过后，我才会把这次备份视为有效。这也是我一直跟团队强调的：备份本身不是目的，能恢复的备份才是目的。

3.4 自动化备份脚本：按日期留档并自动清理

命令行导出数据库一旦要定时执行，最好写成脚本。下面这个脚本是我常用的模板，核心点都带了注释：

#!/bin/bash # 备份脚本 backup_app_db.sh set -e set -o pipefail BACKUP_DIR=/data/backup LOG_FILE=$BACKUP_DIR/backup_$(date +%F).log DB_HOST=127.0.0.1 DB_USER=backup_user DB_PASS='备份用户的密码' DB_NAME=app_db KEEP_DAYS=7 mkdir -p $BACKUP_DIR echo "[$(date +'%F %T')] backup start" >> $LOG_FILE mysqldump -h$DB_HOST -u$DB_USER -p$DB_PASS \ --single-transaction \ --quick \ --set-gtid-purged=OFF \ --routines \ --triggers \ --events \ --hex-blob \ --default-character-set=utf8mb4 \ --databases $DB_NAME \ 2>>$LOG_FILE | gzip > $BACKUP_DIR/${DB_NAME}_$(date +%F).sql.gz echo "[$(date +'%F %T')] backup finished, exit code $?" >> $LOG_FILE # 只保留7天内的备份 find $BACKUP_DIR -name "${DB_NAME}_*.sql.gz" -mtime +$KEEP_DAYS -delete

这里有一个特别容易踩的坑：set -o pipefail。如果不加这行，管道返回的是最后一个命令（gzip）的退出码，gzip 一般是成功的，哪怕 mysqldump 中途失败，脚本也会误以为备份成功。加了pipefail，管道中只要任意环节失败，整体退出码就是失败，脚本才会在定时任务里触发告警。

另外，我不建议把密码明文写在脚本里。比较稳妥的做法是在已授权账号的 home 目录下建一个.my.cnf配置文件：

[client] user=backup_user password=备份用户的密码 host=127.0.0.1

然后执行chmod 600 ~/.my.cnf，脚本里直接写mysqldump即可，它会自动读取配置文件。这样避免命令行暴露密码，也方便定时任务运行。

最后，把脚本加入 crontab：

0 2 * * * /bin/bash /usr/local/sbin/backup_app_db.sh >> /data/backup/cron.log 2>&1

每天凌晨 2 点自动执行一次。定时备份这件事，一旦开始了，就要记得每天早上去翻一下日志，否则哪天备份静默失败，你还会继续收到一堆“备份成功”的假象。

4. 导出过程中的常见坑与排查实录

4.1 mysql ssl连接错误：导出时最磨人的问题

很多人在执行 mysqldump 时遇到过类似报错：

mysqldump: Got error: 2026 (HY000): SSL connection error: error:00000000:lib(0):func(0):reason(0)

MySQL 5.7 和 8.0 默认会尝试启用 SSL 连接，当你使用的客户端版本和服务器 SSL 配置不匹配，或者证书链路有问题时，就可能出现这条错误。特别是服务器上安装了多个 MySQL 客户端，或者本机用 MariaDB 的客户端去连 MySQL 服务端，SSL 兼容性更容易出问题。

我的处理办法，先分清场景再动手：

• 如果是在受信的内网环境、或者只是临时做一次备份，可以显式关闭 SSL 导一次：

mysqldump -uroot -p --ssl-mode=DISABLED \ --single-transaction \ --databases app_db \ > /backup/app_db.sql

• 如果账号被设置为REQUIRE SSL，就不能直接关闭 SSL，而是要把证书参数传对：

mysqldump -uroot -p \ --ssl-ca=/etc/mysql/ca.pem \ --ssl-cert=/etc/mysql/client-cert.pem \ --ssl-key=/etc/mysql/client-key.pem \ --databases app_db > /backup/app_db.sql

• 如果这是备份专用账号，而你确认内网环境通信安全，可以和 DBA 沟通是否调整账号策略，把强制 SSL 改成可选。

注意，关不关 SSL 要结合公司安全规范来，我不建议为了省事直接一刀切关闭。至少你要能说清楚：这个环境里流量是否被隔离、是否有中间人风险。

4.2 权限不足：Access denied 的完整解决过程

另一个高频问题，是使用专用备份账号时提示权限不足：

mysqldump: Got error: 1044: Access denied for user 'backup_user'@'%' to database 'app_db'

mysqldump 的权限要求和普通 SELECT 稍不一样。至少需要：

• SELECT：读取表数据
• SHOW VIEW：读取视图定义
• TRIGGER：读取触发器
• LOCK TABLES：使用锁表参数时用到
• PROCESS：使用--single-transaction时需要
• RELOAD：使用--master-data/--source-data时需要

我通常给备份账号这样授权：

CREATE USER 'backup_user'@'%' IDENTIFIED BY '一个足够复杂的密码'; GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON app_db.* TO 'backup_user'@'%'; GRANT PROCESS, RELOAD ON *.* TO 'backup_user'@'%'; FLUSH PRIVILEGES;

注意，PROCESS 和 RELOAD 是全局权限，不能限定某一个库。如果你还要导出 events，就得额外加上 EVENT 权限；--routines导出存储过程则还要看 definer 相关设置。授权之后，再用备份账号执行同样的导出命令，基本就能解决 1044/1045 问题。

4.3 字符集乱码：导出来中文全是问号

中文乱码是导出问题里的重灾区，现象往往是：导出的 SQL 文件用编辑器打开，中文要么是乱码，要么恢复后前端页面显示出一堆问号。

最常见的原因有三个：

• 导出时命令行客户端连接字符集与数据库不一致，解决办法是统一加--default-character-set=utf8mb4。
• Windows 下用 cmd 或 PowerShell 重定向输出，系统默认代码页干扰了文件编码。这种情况尽量改用--result-file参数：

  mysqldump -uroot -p --default-character-set=utf8mb4 --result-file=C:\backup\app_db.sql app_db

• 恢复时没有指定字符集。导入时也要带上同样的--default-character-set=utf8mb4，否则 INSERT 里的中文仍然可能被目标端用其他字符集解释。

如果你想确认数据库本身的字符集设置，执行：

SHOW VARIABLES LIKE 'character_set_database'; SHOW TABLE STATUS LIKE 'orders';

如果导出文件本身是 UTF-8，但编辑器打开乱码，那多半是编辑器默认按本地代码页（比如 GBK）打开了，手动把编码切到 UTF-8 即可，不是文件坏了。

4.4 磁盘空间不足与导出文件不完整

磁盘空间的坑，比想象中隐蔽。有时候命令执行完，没有输出任何报错，但你看文件大小就觉得不对劲，解压时才暴露问题。

我的经验是分两步确认：

第一步，导出前先df -h，确保目标目录有充足空间。导出一个 30GB 的库，即使压缩后 5GB，也要确保预留至少 10GB 空间，因为压缩过程是边压缩边写，并不是先完整落盘再压缩。

第二步，导出后马上做完整性校验：

# 压缩文件 gzip -t /data/backup/app_db_2025-06-01.sql.gz && echo OK # 未压缩文件，看末尾是不是 Dump completed tail -n 5 /data/backup/app_db.sql

如果末尾不是完整的注释行，而是某条 INSERT 写了一半，说明导出被中断了。产生原因可能是磁盘满、网络断开、连接超时、MySQL 端wait_timeout太短。遇到这种情况，不要抱有侥幸心理，直接重新导一次。也正因为如此，超大表导出我会优先分片，某一片挂了重导那一片就行。

4.5 跨版本导出：8.0 备份导到 5.7 的兼容思路

版本兼容问题属于“低频但一次就致命”的坑。典型的报错是：

ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

原因是 MySQL 8.0 的默认字符集排序规则是utf8mb4_0900_ai_ci，而 MySQL 5.7 不认识。这种情况在把 8.0 的备份恢复到 5.7 时非常常见。

我有几个做法：

• 导出时指定兼容模式：

mysqldump -uroot -p --compatible=mysql57 \ --databases app_db > /backup/app_db_mysql57.sql

这个参数会把部分 8.0 特有语法降级，但并不是万能的。

• 更常用的土办法，是导出后直接对 SQL 文件做文本替换：

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' /backup/app_db.sql

替换之后重新导入，基本就能兼容 5.7 环境。当然，文本替换之前建议先备份原文件，防止替换出错。

另外一个经常被忽略的是认证插件问题：MySQL 8.0 默认使用caching_sha2_password，5.7 默认是mysql_native_password。如果你导出的不仅是数据，还要在新环境重建业务账号，那账号的加密规则也要一起处理。这里就不是 mysqldump 文件能解决的了，需要单独执行账号迁移或调整插件，别把它和 SQL 备份混为一谈。

4.6 最后补充几个容易卡住新手的细节

还有一些不大不小的问题，我顺手列出来，遇到时能省不少时间：

• mysqldump: command not found：说明 mysqldump 不在系统 PATH 里。Linux 下用find / -name mysqldump 2>/dev/null或which mysqldump找一下；Windows 下它在 MySQL 安装目录的bin子目录里。如果实在找不到，就把 MySQL 的bin目录加进 PATH。
• 远程导出主机：mysqldump 同样支持指定主机和端口：mysqldump -h 10.0.0.5 -P 3306 -u root -p --databases app_db > back.sql。前提是防火墙和 MySQL 账号权限允许远程连接。
• 服务没启动就导出会报连接失败：提示Can't connect to MySQL server或错误 2002/2003。先检查 MySQL 服务状态；Windows 下常见的net start mysql服务无法启动问题，根源往往在配置文件或数据目录权限，先把服务跑起来再谈导出。
• mysql>交互终端里不能执行 mysqldump：如果你已经登录到 mysql 客户端里，想用mysqldump会得到语法错误。必须先退出，回到系统 shell 再执行。

把上面这些问题都排查过一遍，再回头看“MySQL 命令行导出数据库”，其实核心就三件事：命令参数选对、字符集和版本考虑清楚、导出后的完整性验证做到位。参数你随时可以查帮助，但意识和流程，只能靠实战积累。

4.7 我平时导出都会多做的几件事

文章的最后，分享几个我自己的固定动作，算不上什么高深技巧，但确实帮我避过很多次灾：

导出的最前方，我会先记下关键表的行数锚点。比如导出前执行SELECT MAX(id) FROM orders;和SELECT COUNT(*) FROM orders;，恢复之后拿来对比。虽然COUNT(*)在大表上会比较慢，但一个月做一次关键业务的恢复演练，这个成本完全值得。

导出完成后，我会立即用gzip -t或zgrep "Dump completed"确认文件完整性，而不是等下次恢复时才傻眼。如果是脚本备份，则一定加上set -o pipefail，防止管道掩盖 mysqldump 的真实退出状态。

更重要的，是我始终记得一句话：备份成功的标志不是“导出没有报错”，而是“能在目标环境完整恢复”。所以我坚持每季度做一次恢复演练，随机抽一个备份文件，导到一台干净的测试实例上，跑一遍数据校验脚本。这个习惯帮我发现过好几次“备份文件存在但恢复不了”的隐患。

如果你刚接触命令行导出，不要被满屏的参数吓住。先跑通最基础的单库导出，再多加--single-transaction和--default-character-set=utf8mb4，把常用的命令保存成自己的笔记或脚本，遇到问题再回来翻这篇文章。命令行导出数据库这笔账，早晚你会靠它省下大把时间。