必须整行删除innodb_file_format配置，不可注释；mysql 8.0已彻底移除该变量，残留会触发my-012609警告或my-000067启动失败，且需同步清理innodb_support_xa、query_cache_type等其他废弃参数。
直接删掉 innodb_file_format 这一行配置，别注释，别保留，连同等号右边的值一起整行删除。 MySQL 8.0 已彻底移除该变量，它不再对应任何内部逻辑，留着只会触发启动警告甚至报错 MY-000067。
为什么删了还报 warning？因为注释没用
很多人把 innodb_file_format=Barracuda 改成 #innodb_file_format=Barracuda 就以为安全了——但 MySQL 8.0 的配置解析器仍可能将含等号的注释行识别为语法异常（尤其当注释里有空格、特殊字符或换行不规范时）。
真正有效的清理方式只有一种：从 my.cnf 或 mysqld.cnf 中物理删除该行。
启动前必须验证配置合法性
改完配置后别急着重启，先运行：
mysqld --defaults-file=/etc/mysql/my.cnf --validate-config
如果输出包含 MY-010918 或 MY-011068，说明还有弃用参数残留；若出现 MY-000067，说明仍有已删除变量未清干净。
常见漏网之鱼包括：innodb_support_xa、innodb_locks_unsafe_for_binlog、query_cache_type。
别信 SHOW VARIABLES 里没它就万事大吉
执行 SHOW VARIABLES LIKE '%file_format%' 返回空结果，不代表配置文件没问题——这只是说明变量没被加载，而错误早在 mysqld 启动解析阶段就发生了。MySQL 8.0 不再暴露 innodb_file_format，也不再维护它的语义，哪怕你设成任意值，它都不会生效，也不会报错（除非启动时读到），但会静默忽略并留下警告日志。
最容易被忽略的是：升级后旧配置里往往混着多个已废弃参数，单删一个 innodb_file_format 不够，得通查全文；另外，云厂商托管实例可能在后台注入额外配置，需确认 mysqld --verbose --help | grep "Default options" 列出的实际加载路径是否包含你修改的那个文件。
