17370845950

mysqldump“Access denied”主因是未显式指定用户密码，应检查-u/-p参数用法、权限及认证插件兼容性；恢复报“Unknown database”因缺少CREATE DATABASE语句，需加--databases参数或手动建库。

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 恢复多库备份 —— 应该用 mysql -D mydb 或先 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 导入纯数据（需提前建表），性能高且绕过 packe

  

  t 限制

恢复后数据不一致或时间戳错乱

根本原因常是备份未启用事务一致性控制，尤其在有写入的生产环境中。

• 务必使用 --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 语句而没验证目标库是否存在。这两点一旦出问题，恢复完成才发现数据缺失，代价远大于重备一次。