mysqldump 是 mysql 中最常用、最稳妥的逻辑备份方式，适合中小规模且对一致性要求不高的场景；它通过 select 生成 insert 语句实现备份，默认加读锁，大库需加 –single-transaction（innodb 有效）避免锁表阻塞业务。
mysqldump 备份单个数据库最常用也最稳妥
直接用 mysqldump 导出 SQL 文件是 MySQL 最主流的逻辑备份方式，适合中小规模、对一致性要求不高的场景。它本质是执行 SELECT 把数据转成 INSERT 语句，所以备份过程会加读锁（除非用 --single-transaction）。
- 基础命令：
mysqldump -u root -p database_name > backup.sql - 带结构和数据（默认行为），加
--no-data只导表结构，加--no-create-info只导数据 - 大库务必加
--single-transaction（InnoDB 表才生效），避免锁表导致业务阻塞 - 中文乱码？导出时加
--default-character-set=utf8mb4，恢复时也要显式指定 - 忽略某个表：用
--ignore-table=database_name.table_name，可多次使用
mysql 命令行恢复 SQL 文件要注意字符集和权限
恢复不是简单 mysql -u root -p 就完事。如果备份时没指定字符集，而目标库默认是 <code>latin1，中文就会变问号；如果 SQL 文件里有 CREATE DATABASE 且当前用户没 CREATE DATABASE 权限，也会失败。
- 先确认目标库存在，或手动建库：
CREATE DATABASE if NOT EXISTS database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 再导入：
mysql -u root -p --default-character-set=utf8mb4 database_name - 如果 SQL 文件开头没有
USE database_name;，必须在命令中指定库名，否则可能导入到错误库 - 遇到
Error 1044 (42000): access denied for user，说明用户缺少INSERT或CREATE权限，需提前授权
跳过某些语句恢复（比如跳过建库/删表）要改 SQL 或用 sed 预处理
有些备份文件开头有 DROP DATABASE 或 CREATE DATABASE，而你只想把数据导入已有库，这时候硬执行会出错或清空数据。
- 临时方案：用
sed '/^CREATE DATABASE|^DROP DATABASE|^USE /d' backup.sql > clean.sql过滤掉关键语句 - 更安全的做法：备份时就控制输出，加
--no-create-db --skip-triggers等参数，减少冗余语句 - 如果 SQL 文件里有
SET FOREIGN_KEY_CHECKS=0;，恢复时一定要保留——否则外键约束会阻止插入 - 注意
DEFINER问题：视图/存储过程里带DEFINER=`user`@`host`，若该用户不存在，恢复会报错，可用sed 's/DEFINER[^*]**/*/g'清除
物理备份（xtrabackup）只适用于 InnoDB 且必须停写或锁表
mysqldump 是逻辑备份，慢、不能热备大库；Percona XtraBackup 是唯一成熟的开源物理备份工具，但仅支持 InnoDB/XtraDB，MyISAM 表只能冷备（停止写入）。
- 全量备份命令：
xtrabackup --backup --target-dir=/path/to/backup/ --user=root --password=xxx - 备份后必须
--prepare（回滚未提交事务、应用日志），否则无法启动：xtrabackup --prepare --target-dir=/path/to/backup/ - 恢复前必须停掉 MySQL，清空原
datadir，再用--copy-back；路径权限要设对（属主必须是mysql:mysql） - 增量备份依赖全量备份，
--incremental-basedir必须指向上次全量或增量目录，顺序错一点就恢复失败
物理备份快但操作门槛高，mysqldump 简单但恢复大库可能卡住几小时；真正线上环境往往两者并存——每天 mysqldump 做逻辑备份，每周用 xtrabackup 做一次物理全备。最容易被忽略的是：备份脚本里没检查磁盘空间，也没验证 SQL 文件是否为空或包含 ERROR 字样。