mysql 5.7 备份不能直接导入 8.0，因系统表结构（如 password→authentication_string）、sql 模式（no_auto_create_user 废弃）、myisam 引擎禁用及 password() 函数移除等硬性冲突导致导入失败；必须只导业务库、清理不兼容语法、替换引擎与密码函数，并调整 sql_mode 后再导入。
不能直接用 mysqldump --all-databases 一把梭，5.7 导出的备份在 8.0 上大概率导入失败——不是语法格式问题，而是系统表结构、SQL 模式、存储引擎、密码函数等硬性不兼容项会立刻报错。
导出时必须只导业务库，且显式指定字符集
导出命令里漏掉 --databases 或误用 --all-databases，就会把 mysql 系统库一起拖进去。5.7 的 mysql.user 表含 password 字段，8.0 已改为 authentication_string；MyISAM 引擎写的系统表在 8.0 里直接被拒。
- 正确写法：
mysqldump -u root -p --databases alarm_system --routines --triggers --events --default-character-set=utf8mb4 > alarm_system.sql - 绝对不要：
mysqldump -u root -p --all-databases > full.sql（哪怕只是想“图省事”） - 导出前先查引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'alarm_system';，确认是否混用 MyISAM - 若存在 MyISAM 表，导出时加
--lock-all-tables（停写前提下），或提前转成 InnoDB
导出后必须手动清理 SQL 文件里的不兼容内容
mysqldump 不会自动降级语法，它照单输出源库定义。5.7 备份文件开头常带 SET sql_mode = 'NO_AUTO_CREATE_USER,STRICT_TRANS_TABLES,...'，而 NO_AUTO_CREATE_USER 在 8.0 中已被移除，导入直接卡死。
将音频或视频文件转录为带时间轴的歌词或字幕格式（如LRC、SRT、WebVTT、ASS、TTML），并制作卡拉OK视频。
- 打开
alarm_system.sql，删掉所有以SET sql_mode =开头的行（或替换为 8.0 兼容值，如STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE） - 搜索并替换所有
ENGINE=MyISAM为ENGINE=InnoDB（尤其注意触发器、视图、存储过程里隐含的 ENGINE 声明） - 搜索
PASSWORD(，替换成SHA2('xxx',256)，或直接删掉——密码应在导入后用ALTER USER重设 - 检查字段名是否撞了 8.0 保留字（如
rank、group、json），有则加反引号，例如`rank` VARCHAR(20)
导入前必须调整目标库的 sql_mode 和字符集环境
即使 SQL 文件改干净了，8.0 默认启用的严格模式仍会拦截旧数据里的非法日期（如 DEFAULT '0000-00-00'）或零日期值，报错 ERROR 1067 (42000): Invalid default value for 'xxx'。
- 导入命令加初始化参数：
mysql -u alarm_user -p --init-command="SET sql_mode=''" alarm_system - 更稳妥的做法：在 8.0 的
my.cnf里临时配置sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION，导入完成后再恢复默认 - 确保目标库已建好且字符集明确：
CREATE DATABASE alarm_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; - 导入时不指定字符集，会按客户端默认读取，可能乱码；务必用
mysql --default-character-set=utf8mb4 -u ...
导入后必须验证外键、自增 ID 和时间精度
mysqldump 默认不导出外键约束（除非加 --skip-opt 或显式开启），且 5.7 和 8.0 对 AUTO_INCREMENT 初始值处理逻辑不同，可能导致主键冲突；另外，5.7 时间类型默认无微秒精度，8.0 默认支持，导出时若没加 --skip-tz-utc 或未同步时区，TIMESTAMP 字段可能偏移。
- 导入后执行：
SELECT COUNT(*) FROM information_schema.KEY_COLUMN_USAGE WHERE CONSTRAINT_SCHEMA = 'alarm_system' AND REFERENCED_TABLE_NAME IS NOT NULL;确认外键是否重建成功 - 检查自增起点：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'alarm_system' AND TABLE_NAME = 'your_table';，必要时用ALTER TABLE ... AUTO_INCREMENT = N;手动修正 - 比对关键时间字段样本，确认是否因时区或精度丢失导致值变更（例如
2023-01-01 12:00:00变成2023-01-01 20:00:00） - 别忽略用户认证插件差异：导入后执行
SELECT User, Host, plugin FROM mysql.user;，若看到mysql_native_password，需运行ALTER USER 'alarm_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'xxx';
最易被跳过的其实是「导入后验证」这一步——很多人看到 Query OK 就以为完事了，但外键失效、自增错位、时间漂移这些坑不会报错，只会让业务在某次 INSERT 或 JOIN 时悄悄崩掉。
