MySQL 8.0已彻底移除innodb_file_format参数，必须从配置文件、命令行及环境变量中全部删除，否则启动时持续报deprecated警告；该参数在运行时已不存在，SET GLOBAL会直接报错“Unknown system variable”。
MySQL 5.7 升级到 8.0 后，innodb_file_format 参数已彻底废弃，继续在配置中保留或运行时设置会触发警告，且不再生效 —— 不用修复，必须删掉。
为什么启动时总看到 “deprecated” 警告？
MySQL 8.0.0 开始移除了对 innodb_file_format 的支持（连同 innodb_file_format_check、innodb_file_format_max、innodb_large_prefix 四个参数）。如果你的 my.cnf 或 my.ini 中还写着：
innodb_file_format = Barracuda
mysqld 启动时就会在错误日志里写一行警告，例如：
[Warning] [MY-012609] The option innodb_file_format is deprecated and will be removed in a future release.
这不是报错，服务仍能起来，但说明配置残留未清理干净。
检查并清除所有残留配置项
这个参数可能藏在多个地方，漏掉任意一处都会持续报 warning：
-
/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf等系统级配置文件 -
~/.my.cnf（用户级，尤其测试环境容易忽略） - 启动命令行中显式传入的
--innodb-file-format=Barracuda（比如 systemd service 文件里的ExecStart） - Docker 容器启动时通过
-e MYSQL_INNODB_FILE_FORMAT=...注入的环境变量（若镜像做了非标适配）
执行以下命令快速定位：
grep -r "innodb_file_format" /etc/my.cnf* /usr/etc/ ~/.my.cnf 2>/dev/null
找到后直接删掉整行，不要注释 —— 注释行仍可能被部分解析器读取并触发警告。
升级前没清配置，升级后又改不了？
如果 MySQL 已在运行，且你尝试用 SET GLOBAL innodb_file_format = Barracuda 动态设置，会立刻收到错误：
ERROR 1193 (HY000): Unknown system variable 'innodb_file_format'
这说明：该变量在 8.0 运行时已完全不存在，不是“只读”，而是“没了”。此时唯一有效动作就是停库 → 清配置 → 重启。
注意：innodb_file_per_table 和 ROW_FORMAT=DYNAMIC 等行为仍有效，只是控制方式变了 —— 它们现在由表定义本身和默认格式策略决定，不再依赖那个废弃参数。
真正需要关注的替代动作
删掉 innodb_file_format 只是清理工作。你真正该做的是确认存量表是否兼容：
- 运行
SELECT TABLE_NAME, ROW_FORMAT, FILE_FORMAT FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE 'db_name/%';检查是否还有FILE_FORMAT=Antelope的表 - 若有，必须在 5.7 环境下完成
ALTER TABLE t1 ROW_FORMAT=DYNAMIC, ALGORITHM=INPLACE;，不能拖到 8.0 再处理 - 8.0 默认只接受
Barracuda格式，Antelope表将无法加载，报Tablespace is missing for table xxx
参数废弃本身不危险，但掩盖了底层格式迁移的真实风险 —— 别让 warning 分散注意力，重点盯住 FILE_FORMAT 和 ROW_FORMAT 的实际值。
