根本原因是mysql 8.0与5.7在字符集、排序规则、sql语法及默认模式上不兼容；导出必须用--compatible=mysql57并配合--default-character-set=utf8mb4等参数，手动清理sql_mode和非法默认值后方可成功导入。
phpEnv 下切换 MySQL 版本后，旧库数据无法直接启动或查询，根本原因不是“数据丢了”，而是表结构定义、字符集、SQL 模式或认证方式在版本间不兼容。必须分层处理：先保结构可读，再保数据可写，最后校验语义一致。
mysqldump 导出时加 --compatible=mysql57 才能导入旧版
从 phpEnv 中的 MySQL 8.0 切换到 5.7 后，直接用默认 mysqldump 导出的 SQL 文件在 5.7 上会报错：Unknown character set: 'utf8mb4_0900_as_cs' 或 You have an error in your SQL syntax。这是因为 8.0 默认用了 5.7 不认识的排序规则和语法糖。
- 导出必须显式降级兼容：
mysqldump --compatible=mysql57 --default-character-set=utf8mb4 -u root -p mydb > dump.sql -
--compatible=mysql57会自动把utf8mb4_0900_as_cs替换为utf8mb4_unicode_ci，并去掉隐藏索引、角色权限等高版本语法 - 别用
--compatible=ansi—— 它会把INT改成INTEGER、ENUM改成字符串模拟，反而增加解析失败概率 - 如果导出的是全库（含
mysql系统库），务必跳过：--skip-triggers --skip-routines --skip-events --ignore-table=mysql.user，系统表结构差异太大，不能直导
导入前手动清理 sql_mode 和非法默认值
即使导出用了兼容参数，导入时仍常卡在 ERROR 1067 (42000): Invalid default value for 'created_at' 或 ERROR 1231 (42000): Variable 'sql_mode' can't be set。这是目标库（如 5.7）开启了严格模式，而 dump 文件里保留了 8.0 的宽松默认值（如 CURRENT_TIMESTAMP 在 DATETIME 字段上）。
- 导入命令中加初始化指令：
mysql -u root -p --init-command="SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';" mydb - 更稳妥的做法是提前用
sed批量替换 dump 文件中的非法默认值：sed -i 's/DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP/DEFAULT \'0000-00-00 00:00:00\'/g' dump.sql - 对
TIMESTAMP字段要特别小心：MySQL 5.7 要求至少一个TIMESTAMP字段带DEFAULT CURRENT_TIMESTAMP，否则建表失败；而 8.0 允许全为NULL。需人工检查并补上
phpEnv 切换版本后，字符集和认证插件必须重配
phpEnv 自动切换 MySQL 版本后，服务能启动，但 PHP 连不上或查出来全是乱码，大概率是两个隐形配置没同步：
- 字符集不一致：8.0 默认
collation_server = utf8mb4_0900_as_cs，5.7 不识别，导致连接后SET NAMES失效。需手动编辑新版本的my.ini，把collation-server改为utf8mb4_unicode_ci，并确认character-set-server = utf8mb4 - 认证插件变更：8.0 默认用
caching_sha2_password，老项目 PDO/MySQLi 连接会报Client does not support authentication protocol。登录新实例后执行：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; - phpEnv 的“数据目录迁移”选项若选了“复制”，实际只是硬链接或路径软跳转，不会转换数据页格式。InnoDB 表空间文件（
.ibd）跨 5.7↔8.0 直接复用会崩溃，必须走逻辑导出导入
抽样验证比行数校验更重要
导入完成后，只跑 SELECT COUNT(*) 对比行数是远远不够的。很多字段看似“数量对得上”，但内容已损坏：比如 TINYINT(1) 被当布尔存成 1/0，导入后变成 49/48（ASCII 码）；或者 JSON 字段在 5.7 下被当成 LONGTEXT 存入，查询时无法用 JSON_EXTRACT。
- 必须抽样查具体字段：
SELECT id, status, created_at, meta FROM orders LIMIT 5;，肉眼核对是否符合业务预期 - 对含中文的字段，用十六进制检查编码：
SELECT HEX(title) FROM posts LIMIT 1;，确认结果是xxxx（utf8mb4 正常）而非C3A9（latin1 误存） - 有 JSON 字段的表，导入后需重建：先删掉原字段，再
ALTER TABLE tbl ADD COLUMN meta JSON;，然后用UPDATE把旧字段内容转过去，避免类型残留
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
