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 客户端又没提前创建目标库。
Yarn - Control and Access Threads.com via the CLI
下载
通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...
- 备份时加
--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 语句而没验证目标库是否存在。这两点一旦出问题，恢复完成才发现数据缺失，代价远大于重备一次。 
