ERROR 1273 (HY000) 根因是本地导出SQL含目标MySQL不支持的排序规则（如utf8mb4_0900_as_cs），需检查版本与collation并替换为兼容值；还原中断则因max_allowed_packet和wait_timeout过小，须同步调大服务端配置与客户端参数。
MySQL 远程还原时出现 ERROR 1273 (HY000)：Unknown collation
根本原因是本地导出的 sql 文件用了服务端不支持的字符集排序规则（比如 utf8mb4_0900_as_cs），而目标 mysql 版本太老（如 5.7 或部分 8.0.20 以下实例）压根不认识这个 collation。
别急着改配置，先确认两边版本和默认 collation：
- 查远程服务器：
SELECT VERSION(), @@collation_server; - 查本地导出文件头：
head -n 20 dump.sql | grep "DEFAULT CHARSET\|COLLATE"
常见解法是导出时就降级兼容性：mysqldump --default-character-set=utf8mb4 --skip-set-charset --collation-server=utf8mb4_unicode_ci ...。如果已导出，用 sed -i 's/utf8mb4_0900_as_cs/utf8mb4_unicode_ci/g' dump.sql 替换（注意备份原文件）。
还原卡在中间、连接中断：不是网络丢包，是 MySQL 的 max_allowed_packet 和超时设置太小
远程还原大 SQL 文件时，MySQL 默认的 max_allowed_packet=4M 和 wait_timeout=28800 往往不够——尤其当单条 INSERT 含大量 JSON 或 BLOB 数据时，客户端还没发完就被服务端断连。
必须两边同步调大：
- 远程服务器配置文件加：
max_allowed_packet = 512M，wait_timeout = 86400，然后重启mysqld - 还原命令里显式指定：
mysql --max-allowed-packet=512M -h xxx -u yyy -p - 如果用管道还原（
cat dump.sql | mysql ...），记得加--force，否则一条错就全停
还原慢 + 高延迟：关掉 autocommit 和唯一性检查，但别关 binlog
远程链路延迟高，每条 INSERT 等一次 ACK 就很伤。默认 autocommit=1 意味着每行都走完整事务流程，网络 RTT 叠加后可能慢 10 倍以上。
安全提速的关键操作：
- 还原前执行：
SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; - 还原完立刻执行：
COMMIT; SET unique_checks=1; SET foreign_key_checks=1; - 千万别设
sql_log_bin=0—— 主从复制会丢数据，且后续 GTID 同步直接崩
注意：这些 SET 只对当前会话生效，不能写进配置文件；如果用脚本还原，确保它们和 source dump.sql 在同一个连接里。
还原后中文乱码或字段截断：字符集没对齐，不只是 utf8mb4 三个字的事
即使都写了 utf8mb4，也可能因 column 级、table 级、connection 级三层字符集不一致导致乱码。典型现象是还原后 SELECT LENGTH(col) 显示长度比预期少一半（说明存成了 latin1）。
必须逐层核对：
- 建表语句里每个
VARCHAR字段是否带CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 还原时连接参数加
--default-character-set=utf8mb4 - 远程服务器
SHOW VARIABLES LIKE 'character_set%'确保character_set_client/server/connection全是utf8mb4
最容易漏的是 client 层：如果用 Python 的 mysql-connector 还原，必须显式传 charset='utf8mb4'，否则默认走 latin1。
