MySQL 8.0不能直接复用旧my.cnf/my.ini，必须针对性适配：移除query_cache_type等废弃参数，替换slave_为replica_，调整sql_mode和default_authentication_plugin，并以官方模板为基础逐项迁移验证。
my.cnf 或 my.ini 不能直接复用于 MySQL 8.0，盲目拷贝会导致服务启动失败或功能异常。MySQL 5.7 和 8.0 在默认配置、参数废弃、安全策略上存在实质性差异，必须做针对性适配。
哪些配置项在 MySQL 8.0 中已被移除或改名
直接复制旧配置最常触发的错误是 Unknown system variable 或 mysqld: Can't recognize option。以下参数在 8.0 中已失效：
-
query_cache_type和query_cache_size：查询缓存彻底移除，保留会报错 -
innodb_file_per_table=OFF：8.0 默认强制开启，设为OFF会被忽略或警告 -
explicit_defaults_for_timestamp：8.0 默认启用，显式设置可能引发兼容性警告 -
sql_mode中的NO_ZERO_DATE、NO_ZERO_IN_DATE等在严格模式下行为更激进，需检查应用是否依赖宽松语义
如何从 5.7 配置安全提取可用部分
不要整份迁移，而是用白名单方式提取真正需要保留的配置：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 只保留路径类配置：
basedir、datadir、socket、pid-file（注意路径权限和 SELinux/AppArmor 是否允许） - 只保留明确业务依赖的存储引擎设置：
default-storage-engine=INNODB（8.0 默认已是 INNODB，但保留无害） - 只保留明确调优过的缓冲区参数：
innodb_buffer_pool_size、max_connections（数值需按新机器内存重新评估） - 跳过所有与复制、日志格式、字符集相关的旧参数，改用 8.0 推荐方式重写（如
binlog_format=ROW仍有效，但log-bin路径需确保目录可写）
备份时该保存什么，而不是整个文件
真正值得备份的不是 my.cnf 文件本身，而是其中反映你业务特征的「决策快照」：
- 记录你实际修改过的非默认值（用
mysql -u root -p -e "SHOW VARIABLES;" > 57-vars.txt导出后筛选） - 记录你依赖的 SQL 模式：
SELECT @@sql_mode; - 记录字符集设定：
SHOW VARIABLES LIKE 'character_set%';和SHOW VARIABLES LIKE 'collation%'; - 记录关键路径权限：
ls -ld /path/to/datadir和ls -l /path/to/datadir/mysql（8.0 初始化后会重建系统表，权限错位会导致启动卡住）
验证新配置是否生效的最小检查项
启动 8.0 后别急着导入数据，先确认配置已正确加载：
- 执行
SELECT @@version;确认确实是 8.0.x - 执行
SELECT @@datadir, @@socket;验证路径是否是你指定的 - 执行
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';看是否读取了你设的值 - 检查错误日志第一行是否有
Server version: 8.0.和mysqld: ready for connections，而非反复重启循环
my.cnf 为基线，仅把 5.7 中经验证确实影响业务的参数逐条加进去，并用 mysqld --defaults-file=/etc/my.cnf --validate-config 提前校验。 
