mysqldump 默认导出结构+全量数据，不加--no-data即包含建表语句和INSERT；常用全库备份命令为mysqldump -u root -p --all-databases > backup.sql，注意权限、字符集（需显式指定--default-character-set=utf8mb4）及大库性能优化（启用--quick、禁用--opt）。
mysqldump 备份整个数据库时，不加 --no-data 就默认导出结构 + 数据
很多人以为 mysqldump 默认只导出表结构，其实不是。只要没加 --no-data，它就会把建表语句和所有 INSERT 语句一起写进文件——也就是“结构 + 全量数据”。这是最常用也最稳妥的全库备份方式。
实操建议：
- 用
mysqldump -u root -p --all-databases > backup.sql备份所有库（含mysql系统库），但要注意权限和密码安全 - 若只想备份某个库，用
mysqldump -u root -p mydb > mydb.sql，更轻量、恢复更精准 - 加
--single-transaction可避免锁表（仅对 InnoDB 有效），适合线上业务库 - 不加
--routines和--events，存储过程、函数、事件不会被导出
导出结构不带数据：必须显式加 --no-data
想只保留建表语句、视图定义、索引等 DDL，去掉所有 INSERT，就得靠 --no-data。它不等于“空库”，而是“零行数据的完整结构”。
常见错误现象：
- 误以为加了
-d（其实是--no-data的简写）就自动包含触发器——错，--triggers要单独加 - 用
--no-data导出后发现视图没内容：因为视图定义默认不导出，得加--skip-triggers配合--routines才能保全逻辑 - 导出的 SQL 文件里出现
CREATE DATABASE IF NOT EXISTS：这是默认行为，如需跳过，加--skip-create-db
中文乱码或特殊字符报错：关键是 --default-character-set
如果库/表用的是 utf8mb4，但导出时没指定字符集，mysqldump 可能按 latin1 解析，导致注释、字段值变成乱码，甚至 ERROR 1267 (HY000)。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
使用场景：
- 导出前先查源库字符集：
SHOW CREATE DATABASE mydb;看DEFAULT CHARACTER SET - 导出命令中必须加
--default-character-set=utf8mb4，且要放在用户名密码之后、库名之前 - 如果目标 MySQL 版本较老（如 5.5），
utf8mb4可能不被识别，此时降级为utf8，但会丢掉 emoji 等四字节字符 - 生成的 SQL 文件开头会有
SET NAMES utf8mb4;，这是恢复时生效的关键
大库导出慢 / 内存溢出：别只盯着 --quick，还得关掉 --opt
--opt 是默认开启的复合选项（含 --add-drop-table、--lock-tables 等），对小库友好，但对百 GB 级 InnoDB 库反而拖慢速度、吃光内存。
性能影响点：
-
--quick（即-q）强制逐行读取，避免把整张表加载进内存，必须加 - 显式关闭
--opt（用--skip-opt），再手动打开需要的子项，比如只留--add-drop-table和--create-options - 加
--compress对网络传输有帮助，但本地导出反而增加 CPU 开销，一般不用 - 导出单表超 10GB 时，考虑配合
split分割文件，或改用mydumper这类并行工具
真正容易被忽略的是：导出时的 MySQL 服务端配置，比如 max_allowed_packet 如果小于单条大 INSERT，会导致导出中断且无明确提示。调高它比折腾客户端参数更治本。
