error 1045/2002 等属连接级错误，非sql问题：1045为认证或权限失败，2002/2003为服务未启或socket路径错误；需检查服务状态、日志、权限及备份完整性。
ERROR 1045 / ERROR 2002 这类连接级报错，先别急着修SQL
这类错误根本不是数据或语法问题，而是连数据库这扇门都没敲开。ERROR 1045 表示账号密码错或权限不足；ERROR 2002 或 ERROR 2003 则说明 MySQL 进程根本没跑起来，或者 socket 文件路径对不上。
- 用
systemctl status mysql确认服务状态，失败时立刻查journalctl -u mysql --since "1 hour ago" - 检查 socket 路径是否一致：运行
mysql --socket=/var/run/mysqld/mysqld.sock -u root -p显式指定，比依赖默认路径更可靠 - 如果提示 “Access denied for user 'backup_user'@'localhost'”，不是密码错了，而是该用户压根没被授予
SELECT、LOCK TABLES、RELOAD等基础权限——用 root 执行GRANT SELECT, LOCK TABLES, RELOAD ON *.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES;
恢复时卡在 “ERROR 1153” 或客户端静默断连，大概率是包大小惹的祸
max_allowed_packet 是 MySQL 客户端和服务端之间传输单个 SQL 包的最大字节限制。mysqldump 导出的大文件一导入，就容易超限，表现为命令中途退出、无报错、表只建了一半。
- 临时调大：登录 MySQL 后执行
SET GLOBAL max_allowed_packet = 536870912;（512MB） - 永久生效：在
/etc/mysql/my.cnf的[mysqld]和[client]段都加上max_allowed_packet = 512M，然后重启服务 - 验证是否生效：
SHOW VARIABLES LIKE 'max_allowed_packet';，注意单位是字节，512M 对应 536870912
ERROR 1064 语法错误？别急着改 SQL，先看导出参数和目标版本
“You have an error in your SQL syntax” 这类报错，90% 不是 SQL 写错了，而是备份时用了高版本特性，却往低版本 MySQL 里硬塞。比如 MySQL 8.0 导出的 CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci，在 5.7 上就会报错。
Modoer 是一款以本地分享，多功能的点评网站管理系统。采用 PHP+MYSQL 开发设计，开放全部源代码。因具有非凡的访问速度和卓越的负载能力而深受国内外朋友的喜爱。在升级前一定要备份好自己的原版本，特别是自己设计了模板和修改了代码的用户。Modoer多功能点评系统 v1.2.5 Build 20111220更新列表修正 安全漏洞和安全隐患增加 后台登陆和SQL错误记录日志修复 若干小BUG
- 导出时加兼容参数：
mysqldump --compatible=mysql40 --set-gtid-purged=OFF -u root -p mydb > backup.sql - 确认目标实例是否启用 GTID：若未开启，必须加
--set-gtid-purged=OFF，否则头几行会写入SET @@GLOBAL.GTID_PURGED，直接报错 - 检查字符集：若导入后出现
Incorrect string value，说明字段定义用了utf8mb4_0900_ai_ci而目标库不支持，导出时强制指定--default-character-set=utf8mb4，导入前执行SET NAMES 'utf8mb4'
从 error.log 里找线索，别只盯着终端那一行红字
MySQL 错误日志才是真相现场。终端报错只是冰山一角，真正关键的上下文（比如表空间 ID 不匹配、磁盘满、ibdata1 权限异常）全在日志里。
- 先定位日志路径：
SHOW VARIABLES LIKE 'log_error';，常见位置是/var/log/mysql/error.log或/var/lib/mysql/hostname.err - 重点搜关键词：
ERROR、InnoDB、Tablespace、Can't open、Permission denied - 典型陷阱：物理恢复后启动失败，日志里出现
InnoDB: Operating system error number 13—— 这不是文件损坏，而是/var/lib/mysql目录下文件权限不对，用chown -R mysql:mysql /var/lib/mysql和chmod -R 755 /var/lib/mysql修复，千万别暴力chmod -R 777
实际恢复中最容易被跳过的，是校验备份文件本身是否完整。哪怕所有配置都对了，一个被截断的 backup.sql 或者解压不全的 RDS 备份包，都会让前面所有排查白费力气。每次 restore 前，至少执行一次 head -n 20 backup.sql 和 md5sum backup.sql 对比原始哈希值。
