MySQL 8.0 启动报错 MY-000067 表明配置文件中存在已被官方彻底移除的变量（如 query_cache_type、time_zone 等），需删除对应行并改用新参数（如 default-time-zone）；同时确认配置路径在默认加载顺序内、节名正确为 [mysqld]、语法规范。
参数被官方移除，启动直接报错 MY-000067
MySQL 8.0 启动时遇到 MY-000067 错误，提示 unknown variable 'xxx'，基本可断定该参数已被彻底删除。这不是加载顺序或权限问题，而是代码层移除——配置项在源码中已不存在。
-
query_cache_type和query_cache_size：8.0.3 起完全移除，删掉配置文件里所有相关行 -
innodb_file_format、innodb_file_format_max、innodb_large_prefix：WL#7704 移除旧文件格式支持，必须删除 -
innodb_support_xa、innodb_locks_unsafe_for_binlog：WL#8843 / WL#8894 删除，留着会导致启动失败 -
time_zone=+8:00：语法错误，正确写法是default-time-zone="+8:00"（注意是default-time-zone，不是time_zone）
查证方式：访问 MySQL 8.0 官方文档 “Removed System Variables” 页面，逐项核对；不要依赖旧版配置模板。
参数虽保留但行为变更，值看似生效实则无效
有些参数名还在，但语义或默认值已变，导致配置“看起来起作用”，实际运行逻辑不符预期。
-
local_infile：5.7 默认为ON，8.0 默认为OFF；若未显式配置，应用执行LOAD DATA INFILE会静默失败 -
sql_mode：8.0 默认启用STRICT_TRANS_TABLES等严格模式，旧配置若覆盖为宽松模式（如只写NO_ENGINE_SUBSTITUTION），可能掩盖数据截断风险 -
expire_logs_days：仍被兼容，但官方推荐改用binlog_expire_logs_seconds；若两者共存，后者优先，前者被忽略 -
max_connections：8.0 对动态设置加了隐式限制（如不能低于 10），仅靠SET GLOBAL修改可能被拒绝，必须写入配置文件并重启
验证方法：登录后执行 SELECT @@global.sql_mode; 或 SHOW VARIABLES LIKE 'local_infile';，看输出是否与配置文件一致，而非只信配置文件内容。
配置路径没被读取，/www/server/mysql/my.cnf 白写了
宝塔等面板用户常把 my.cnf 放在 /www/server/mysql/ 下，重启后参数不生效——根本原因是 MySQL 8.0 启动时不扫描该路径。
- 真实加载顺序由编译时硬编码决定，执行
mysqld --verbose --help | grep "Default options"可见典型路径：/etc/my.cnf→/etc/mysql/my.cnf→/usr/local/mysql/etc/my.cnf→~/.my.cnf -
/www/server/不在任何默认路径中，且无通配符或递归机制，放那里等于没配 - 部分环境存在多个
my.cnf（如/etc/my.cnf和/etc/my.cnf.d/server.cnf），后加载的会覆盖前面的同名参数
解决动作：统一把有效配置挪到 /etc/my.cnf（Linux RPM 安装最稳妥），删掉其他位置的冗余文件；修改后务必用 mysqld --print-defaults 确认参数是否出现在输出中。
配置文件语法或节名错误，[client] 和 [mysqld] 混用
INI 格式对节名敏感，写错节名或把服务端参数塞进客户端节，会导致参数被忽略而不报错。
-
[client]下的参数只影响 mysql 命令行客户端（如user、password、socket），innodb_buffer_pool_size放这里完全无效 -
[mysqld]是唯一影响服务端行为的节名，拼错成[mysql]或[mysqld_safe]（后者仅控制守护进程，不传参给 mysqld）都会失效 - 注释符号必须是
#或;，//或/* */不被识别，可能造成后续配置解析中断 - 数值单位写法要规范：
2G可识别，2 GB或2g（小写 g）可能被忽略或解析为 0
最容易被忽略的是：MySQL 8.0 不再支持 !include 指令（某些旧发行版补丁曾添加），想拆分配置必须靠外部工具合并，不能指望自动加载子文件。
