mysqldump 备份单表必须指定数据库名，格式为 mysqldump -u user -p database_name table_name > backup.sql；需加 --no-create-info 仅导数据，--default-character-set=utf8mb4 避免乱码，InnoDB 大表应加 --single-transaction。
mysqldump 备份单表时必须指定数据库名
不写数据库名，mysqldump 会直接报错 ERROR 1049 (42000): Unknown database 'xxx' —— 它根本不会“自动猜”你在哪个库下操作。单表备份本质是「从某库中导出某表」，所以 database_name table_name 是强制顺序。
实操建议：
- 先用
mysql -u root -p -e "SHOW DATABASES;"确认库名拼写（注意大小写，Linux 下敏感） - 命令格式固定为：
mysqldump -u user -p database_name table_name > backup.sql - 如果表名含特殊字符或关键字（如
order），需用反引号包裹：mysqldump ... db_name `order` > backup.sql
只导数据不导建表语句？用 --no-create-info
默认 mysqldump 会把 CREATE TABLE 和 INSERT 一起导出。但很多场景（比如补数据、迁移记录）只需要纯 INSERT，否则恢复时可能因表结构冲突失败。
常见错误现象：恢复时提示 Table 'xxx' already exists 或字段数不匹配，就是因为没关掉建表逻辑。
实操建议：
- 加
--no-create-info只导数据：mysqldump -u u -p --no-create-info db t > data_only.sql - 若还要跳过外键检查（避免导入时报错），顺手加上
--skip-extended-insert（生成多行 INSERT，方便调试）和--disable-keys（加快导入） - 注意：
--no-create-info不影响USE database_name语句，恢复前仍需确保目标库存在
中文乱码或 emoji 存储异常？重点看字符集参数
导出 SQL 文件里中文变问号、emoji 报错 Incorrect string value，大概率是客户端与服务端字符集不一致，而 mysqldump 默认用 latin1 连接。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
性能与兼容性影响：不显式指定字符集，可能导致大表导出后无法原样恢复，尤其在 MySQL 8.0+ 默认 utf8mb4 的环境下更明显。
实操建议：
- 强制用
utf8mb4：加参数--default-character-set=utf8mb4 - 同时确保服务端 my.cnf 里
[client]和[mysqld]段落的character-set-server也是utf8mb4 - 验证是否生效：导出文件开头应有
SET NAMES utf8mb4;，而不是latin1
大表导出卡住或内存溢出？用 --single-transaction 和分块
对千万级以上表直接 mysqldump，容易锁表（MyISAM）或耗尽内存（InnoDB），甚至触发 OOM Killer 杀掉进程。不是命令写错了，是默认行为不适合大表。
使用场景：线上业务库不能停写，又需要一致性快照；或者服务器内存小于表大小的 2 倍。
实操建议：
- InnoDB 表优先用
--single-transaction（基于 MVCC，不锁表） - 配合
--skip-triggers --skip-routines --skip-events减少元数据开销 - 真要分片导出？
mysqldump本身不支持，得靠WHERE条件切分，例如：mysqldump -u u -p db t --where="id BETWEEN 1 AND 100000" > part1.sql
最常被忽略的是字符集参数和数据库名的强制绑定——很多人试了三次都失败，其实只是漏写了库名，或者本地终端编码和 MySQL 服务端不一致。导出前花三十秒确认这两点，比查半天日志快得多。
