mysqldump 备份时出现 “Access denied” 错误
这通常不是权限配置遗漏，而是
mysqldump连接时未显式指定用户或密码，导致尝试用空用户/空密码连接，触发 MySQL 的默认拒绝策略。 确认是否用了
--user和
--password（或
-u/
-p），注意
-p后不加空格再跟密码（否则会被当作数据库名） 避免在命令行中明文写密码：改用
mysql_config_editor设置登录路径，再用
--login-path=xxx检查用户是否具有
SELECT、
LOCK TABLES（非 --single-transaction 模式下）、
SHOW VIEW（含视图时）等权限 若用 root 用户但提示拒绝，可能是 MySQL 8.0+ 默认认证插件为
caching_sha2_password，而旧版客户端不兼容 —— 可临时用
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';切换
恢复时遇到 “Unknown database” 或 “Table doesn’t exist”
本质是 SQL 文件里缺少
CREATE DATABASE语句，或
USE语句指向了不存在的库，而
mysql客户端又没提前创建目标库。 备份时加
--databases参数（如
mysqldump --databases mydb > backup.sql），它会自动包含
CREATE DATABASE IF NOT EXISTS和
USE语句 若备份不含库结构（例如只用
mysqldump mydb），恢复前必须手动执行
CREATE DATABASE IF NOT EXISTS mydb;检查 SQL 文件开头是否有
USE `mydb`;；若库名含特殊字符或大小写敏感（Linux 下），确保文件中的库名与实际一致（MySQL 配置
lower_case_table_names=1会影响匹配） 不要直接用
mysql 恢复多库备份 —— 应该用 <code>mysql -D mydb 或先 <code>source backup.sql在已选库内执行
导入大 SQL 文件卡住或报 “Got a packet bigger than ‘max_allowed_packet’”
这是 MySQL 服务端和客户端对单个数据包大小的限制不一致导致的，常见于含大 BLOB 或长 INSERT 的备份文件。
查看当前值：mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"临时提升（需同时设服务端和客户端）：
mysql --max_allowed_packet=512M -u root -p mydb < backup.sql，并在
my.cnf中添加
max_allowed_packet = 512M（重启 mysqld） 若仍失败，可拆分 SQL 文件：用
split -l 5000 backup.sql backup_part_按行切分，再逐个导入（注意确保每段不切断 INSERT 语句） 更稳妥的方式是用
mysqlimport或
LOAD DATA INFILE导入纯数据（需提前建表），性能高且绕过 packet 限制
恢复后数据不一致或时间戳错乱
根本原因常是备份未启用事务一致性控制，尤其在有写入的生产环境中。
务必使用--single-transaction（InnoDB 表适用），它通过 START TRANSACTION WITH CONSISTENT SNAPSHOT 获取一致性快照，避免锁表又保证逻辑一致 禁用
--lock-tables（默认开启），它会导致 MyISAM 表被锁，而 InnoDB 表可能因不同步锁产生不一致 检查备份文件中是否有
SET TIMESTAMP=...或
SET TIME_ZONE=...语句 —— 若服务器时区与备份时不同，可能影响
DATETIME字段；建议备份时加
--skip-tz-utc并统一用 UTC 存储 恢复后立即校验：
SELECT COUNT(*) FROM tbl;对比备份前后，再抽样查几条带主键和时间字段的记录 实际操作中最容易被忽略的是：备份命令里漏掉
--single-transaction却以为“没报错就是一致”，以及恢复时盲目信任 SQL 文件头部的
USE语句而没验证目标库是否存在。这两点一旦出问题，恢复完成才发现数据缺失，代价远大于重备一次。
