这是mysql版本不兼容导致的unknown system variable错误，因变量在当前版本不存在、已移除或作用域受限（如只读或仅全局），需按版本查文档、验证配置并区分set session/global适用范围。
这是 MySQL 版本不兼容导致的典型报错，不是配置写错了，而是你试图设置一个旧版本不存在、或新版本已移除的系统变量。
确认变量是否真实存在且可动态修改
MySQL 不同大版本（5.7 / 8.0 / 8.4）对系统变量的支持差异很大，比如 query_cache_type 在 8.0.23+ 已被彻底移除，explicit_defaults_for_timestamp 在 8.0.26+ 变为只读。直接执行 SET GLOBAL xxx = 1 或在配置文件里写 xxx=1 就会触发 Unknown system variable 错误。
实操建议：
- 先查当前版本支持的变量：
SELECT VARIABLE_NAME, VARIABLE_SCOPE, SET_TIME FROM performance_schema.variables_info WHERE VARIABLE_NAME LIKE '%your_var%'; - 重点看
VARIABLE_SCOPE字段：若为GLOBAL才能用SET GLOBAL；若为READ_ONLY，说明只能在启动时通过配置文件设置（且可能已被弃用） - 检查官方文档对应版本的「Server System Variables」页，不要参考 5.7 的文档去配 8.4
配置文件中写错变量名或放错位置
常见错误是把仅适用于 [mysqld] 段的变量写进 [client] 或 [mysql] 段，或者拼写错误（如把 innodb_buffer_pool_size 写成 innodb_buffer_pool_sz），MySQL 启动时无法识别就报这个错。
实操建议：
- 用
mysqld --verbose --help | grep -A 1 "Default options"查看 MySQL 实际加载的配置文件路径 - 用
mysqld --defaults-file=/etc/my.cnf --validate-config（8.0.14+ 支持）验证配置语法，它会明确指出哪一行哪个变量不合法 - 确保所有服务端变量都严格放在
[mysqld]段下，且变量名与SHOW VARIABLES输出完全一致（区分大小写在某些系统上生效）
客户端连接时 SET 语句触发该错误
有些变量根本不能在会话级设置，比如 max_connections、log_bin，它们只接受全局设置或启动参数。但用户常在应用连接池初始化 SQL 里写 SET SESSION max_connections = 1000，结果一连就报错。
实操建议：
- 区分
SET SESSION和SET GLOBAL的适用范围：只有VARIABLE_SCOPE显示BOTH或SESSION的才能用SET SESSION - 应用层初始化 SQL 应只设安全、可变的会话变量，如
time_zone、sql_mode、wait_timeout；避免硬编码任何带max_、log_、innodb_前缀的变量 - 如果 ORM（如 Django、Laravel）自动生成初始化 SET，请关闭该功能，改用连接参数或数据库级默认值
最易被忽略的是：MySQL 8.0 默认启用 sql_require_primary_key，而很多旧应用的建表语句没主键，连上去立刻报错——但它报的不是主键错误，而是先卡在某个被废弃的兼容性变量上。遇到这类问题，别急着改代码，先用 mysqld --no-defaults --verbose --help 看启动时实际加载了哪些变量，再逐个比对版本文档。
