mysql配置不生效是因为配置根本未被读取或被其他同名文件覆盖，主因包括：加载顺序固定（/etc/my.cnf→/etc/mysql/my.cnf→…）、权限非法（如组/其他可写）、参数位置错误（如sql_mode未置于[mysqld]段）、语法错误导致静默跳过、systemd命令行参数覆盖及windows权限问题。
不是“自动失效”，而是配置根本没被 MySQL 读到，或者被其他位置的同名配置覆盖了。
my.cnf 被忽略的常见原因
MySQL 启动时只加载它“认为该加载”的那个配置文件，路径和顺序是硬编码的。Linux 下默认按以下顺序查找（遇到第一个就停）：
/etc/my.cnf/etc/mysql/my.cnf/usr/etc/my.cnf~/.my.cnf
如果你改的是 /etc/my.cnf，但实际生效的是 /etc/mysql/my.cnf（比如 Ubuntu/Debian 默认用这个），那你的修改就完全无效。
验证方法：运行 mysqld --verbose --help | grep "Default options"，它会打印出 MySQL 实际扫描的配置路径列表。
sql_mode 或 max_connections 等参数不生效
这类参数必须放在 [mysqld] 段落里，且不能出现在其他段落（如 [client] 或 [mysql]）中。如果写成这样：
[mysqld] sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE [client] sql_mode=ONLY_FULL_GROUP_BY
——那么 [client] 里的 sql_mode 对服务端毫无作用，而 [mysqld] 的设置才有效。但更隐蔽的问题是：如果 my.cnf 文件里有语法错误（比如漏了 [mysqld] 头、多了一个等号、引号不配对），MySQL 会静默跳过整个文件，退回到内置默认值。
检查方式：
- 用
mysqld --defaults-file=/etc/my.cnf --verbose --help测试是否能正常解析 - 查错误日志（
log-error指定的位置），看是否有unknown variable或syntax error类提示
systemd 环境下配置被绕过
在 CentOS 7+/Ubuntu 16.04+ 上，如果用 systemctl start mysql 启动，MySQL 实际可能通过 ExecStart 直接调用二进制并传参，例如：
ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION
这时，如果 $MYSQLD_OPTS 里硬编码了 --sql-mode=...，就会覆盖 my.cnf 中的设置；或者 --defaults-file 被显式指定为另一个文件，你的 /etc/my.cnf 就彻底失效。
排查命令：
-
systemctl cat mysql—— 查看服务定义 -
ps aux | grep mysqld—— 看实际启动命令行参数
Windows 上 my.ini 权限或路径问题
Windows 下 MySQL 服务常以 NETWORK SERVICE 或本地系统账户运行，它可能没有权限读取你编辑的 my.ini（尤其是放在 C:\Program Files\ 下时）。更麻烦的是，MySQL 会优先读取 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini，而不是安装目录下的那个。
典型表现：
- 你改了
D:\mysql\my.ini，但服务仍按默认值启动 - 用
mysqld --console启动却正常——因为命令行启动时当前目录不同，读取逻辑也不同
解决办法：确认 my.ini 在 C:\ProgramData\MySQL\MySQL Server 5.7\，且 NETWORK SERVICE 对该文件有“读取”权限（右键 → 属性 → 安全 → 编辑）。
最易被忽略的一点：MySQL 5.7 不会报错退出，当配置无效时它只是沉默地用内置默认值继续运行。你以为改成功了，其实连配置文件都没加载上。
