mysql变量永久生效必须写入实际加载的my.cnf（或my.ini）文件的[mysqld]段落，重启服务后才生效；set global仅会话级有效，重启即丢失。
直接改 my.cnf 才算真正永久生效
临时用 SET GLOBAL 修改的变量，MySQL 重启后全丢。真要永久化，必须写进配置文件——不是随便哪个文件，而是 MySQL 实际加载的 my.cnf（或 my.ini，Linux 下基本是前者）。
关键不是“改了就行”，而是得确认 MySQL 启动时真读了你改的那一个。常见错误是改了 /etc/my.cnf，但 MySQL 实际加载的是 /etc/mysql/my.cnf 或用户家目录下的 ~/.my.cnf。
查它到底读哪个：mysql --help | grep "Default options"
输出类似：Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
按这个顺序，第一个存在的文件才生效。优先改最靠前、且实际被使用的那个。
[mysqld] 段落里加参数，别写错位置
所有服务端变量（比如 max_connections、innodb_buffer_pool_size、wait_timeout）必须放在 [mysqld] 段落下，不能塞在 [client] 或裸露在文件开头。否则 MySQL 启动时会忽略，甚至报错退出。
示例（正确）：
[mysqld]<br>max_connections = 500<br>wait_timeout = 28800<br>innodb_buffer_pool_size = 2G
常见踩坑：
• 把
sql_mode 写成 sql_mode = STRICT_TRANS_TABLES（缺引号，新版 MySQL 会启动失败）• 用 KB/MB/GB 单位时写成
sort_buffer_size = 2m（必须大写 M，小写会被当作文本忽略）• 在
[mysqld] 外写变量，比如直接跟在注释后面
改完必须重启 mysqld，不是 reload
systemctl reload mysql 或 mysqladmin reload 不会重新读取 my.cnf 中的变量——它只重载权限表和部分缓存。只有完整重启服务，才能让新配置生效：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
sudo systemctl restart mysql
重启后立刻验证：mysql -e "SHOW VARIABLES LIKE 'max_connections';"
注意：如果变量值没变，先检查 MySQL 错误日志：sudo journalctl -u mysql -n 50 --no-pager
常见报错：
• Unknown variable 'xxx' → 变量名拼错，或该版本不支持
• Cannot load from mysql.proc → 配置语法错误导致初始化失败
• 启动卡住 → 内存类参数（如 innodb_buffer_pool_size）设得太大，超出物理内存
别漏掉权限和备份，尤其生产环境
编辑 my.cnf 是高危操作。没备份、没验证就改，可能直接导致 MySQL 启不来。
实操清单：
• 改前先备份：sudo cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak-$(date +%Y%m%d)
• 修改后用 sudo mysqld --defaults-file=/etc/mysql/my.cnf --validate-config（MySQL 8.0.21+ 支持）做语法校验
• 如果用 Docker 或 systemd 启动，确认它没覆盖配置路径（比如通过 EnvironmentFile= 或 ExecStart 参数硬编码了配置位置）
• innodb_buffer_pool_size 这类内存参数，建议设为物理内存的 50%–75%，别盲目堆大
最常被忽略的一点：有些变量（如 event_scheduler）虽然能 SET GLOBAL，但它的默认值由配置文件控制；如果你希望服务一启动就开启调度器，就必须在 [mysqld] 里写 event_scheduler = ON，而不是指望每次连上去手动开一次。
