MySQL 8.0默认认证插件变为caching_sha2_password，导致旧客户端（如Navicat 12、JDBC 5.x）连接失败报“Access denied”；解决方法为执行ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pass'并FLUSH PRIVILEGES，或升级驱动并配置allowPublicKeyRetrieval=true。
mysql_native_password 认证插件失效导致客户端连不上
升级后 root 或其他用户突然无法登录，错误是 Access denied for user，大概率是认证插件从 mysql_native_password 切到了 caching_sha2_password。旧版 JDBC（5.x）、PHP mysqli、Navicat 12 及更早版本都不支持这个新插件。
- 临时解法：立即执行
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pass';，再FLUSH PRIVILEGES; - 长期方案：若必须用新插件，JDBC 连接串必须加
?serverTimezone=UTC&allowPublicKeyRetrieval=true，且驱动版本不低于mysql-connector-java:8.0.28 - 别漏查所有用户：
SELECT User, Host, plugin FROM mysql.user;，批量改的话用WHERE plugin = 'caching_sha2_password'
utf8mb4_0900_ai_ci 排序规则引发 Illegal mix of collations 错误
导入或查询时爆出 Illegal mix of collations，不是字符集没设对，而是排序规则混用——5.7 常用 utf8mb4_general_ci，8.0 默认 utf8mb4_0900_ai_ci，两者不能隐式转换。
- 导出时加参数：
mysqldump --default-character-set=utf8mb4 -u root -p - 建库时显式指定：
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 查混用表：
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_COLLATION NOT LIKE 'utf8mb4_0900_ai_ci';，逐个ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
local_infile 默认关闭导致 LOAD DATA LOCAL INFILE 失败
升级后执行 LOAD DATA LOCAL INFILE 直接报错 ERROR 3948 (42000): Loading local data is disabled，因为 8.0 的 local_infile 默认值从 5.7 的 ON 改为 OFF。
- 运行时开启：
SET GLOBAL local_infile = ON;（仅当前会话生效） - 永久生效：在
my.cnf的[mysqld]段下添加local_infile = ON，重启 MySQL - 注意配合
secure_file_priv路径，否则即使开也报错
STRICT_TRANS_TABLES 触发字段默认值缺失报错
插入数据时突然报 ERROR 1364 (HY000): Field doesn't have a default value，不是数据有问题，是 8.0 默认启用严格模式，而 5.7 很多表的 NOT NULL 字段没设 DEFAULT。
- 查问题字段：
SHOW CREATE TABLE t_name;找出无默认值的NOT NULL列 - 补默认值：
ALTER TABLE t MODIFY COLUMN c VARCHAR(255) DEFAULT '' NOT NULL;（按类型选合适默认值） - 不建议临时关 strict：
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';—— 已有连接不生效，且掩盖真实结构缺陷
caching_sha2_password + utf8mb4_0900_ai_ci + STRICT_TRANS_TABLES 一起触发，错误日志里只显示最外层报错，底层原因得一层层剥。每次改完一个配置，务必验证对应路径的业务 SQL 是否真能跑通，而不是只看 MySQL 启动成功。 
