MySQL自身不审计配置文件变更，需依赖操作系统监控（如inotifywait或auditd）；配置中心须强化访问控制与签名验证；mysqld按固定顺序加载my.cnf，需用--print-defaults确认生效文件；参数生效方式依作用域而定，动态修改优先用SET PERSIST，重启前应测试启动。
mysql配置文件被改了怎么发现
MySQL本身不记录my.cnf或my.ini的修改时间或内容变更，靠它自己“审计”配置文件变动根本不可能。真正能抓到变更的，是操作系统层面的文件监控机制。
常见错误现象：SHOW VARIABLES看到参数值变了，但翻遍mysqld.log和error log都找不到谁改的、什么时候改的；重启后生效，但没人承认动过配置。
- 用
inotifywait -m -e modify,attrib /etc/my.cnf实时监听（需安装inotify-tools） - 生产环境建议配合
auditd：加规则-w /etc/my.cnf -p wa -k mysql_config，之后用aureport -f -i -k mysql_config查记录 - 注意：Docker容器内监听宿主机路径无效，得在容器启动时挂载
/etc/audit/rules.d/并启用auditd
mysql配置中心怎么防未授权修改
所谓“配置中心”，如果只是把my.cnf扔进Git或Consul，没做访问控制和签名验证，那跟共享网盘没区别。MySQL进程启动时读取配置是无鉴权行为，关键在分发环节。
使用场景：K8s里用ConfigMap挂载配置、Ansible批量推送、运维平台生成并下发my.cnf。
- Git仓库必须设为私有，分支保护开启
require pull request reviews，禁止直接push到main - Ansible playbook里避免明文写
mysql_password，用ansible-vault加密敏感段，且copy模块加validate: 'mysqld --defaults-file=%s --verbose --help &>/dev/null'校验语法 - Consul/KV中存储的配置项，必须通过ACL策略限制
read权限，且write只开放给CI流水线专用token
mysqld启动时加载哪个my.cnf
MySQL按固定顺序搜索配置文件，顺序错了，改对了文件也白搭。最常踩的坑是以为改了/etc/my.cnf就万事大吉，结果mysqld优先读了~/.my.cnf或/usr/etc/my.cnf。
执行mysqld --help --verbose | grep "Default options"能列出全部候选路径，典型顺序是：/etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf。
- 用
mysqld --print-defaults确认最终生效的是哪几个文件（它会输出实际合并后的所有参数） -
~/.my.cnf里若存在[client]段，会影响mysql命令行工具，但不会影响mysqld服务启动 - Docker官方镜像默认只读
/etc/mysql/my.cnf，自定义镜像务必检查ENTRYPOINT是否覆盖了--defaults-file
配置变更后如何安全生效
不是所有参数都能在线改，也不是所有改完都要重启。乱重启可能触发复制中断、连接闪断、甚至表损坏。
性能影响明显：比如innodb_buffer_pool_size调大要重启，但max_connections可动态设；sql_mode改了只影响新连接，旧连接不变。
- 先查
SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME IN ('xxx');确认作用域（GLOBAL/BOTH/SESSION） - 动态修改用
SET PERSIST（8.0+），它会写入mysqld-auto.cnf，比直接改my.cnf更可控；但注意该文件权限必须是mysql:mysql且600 - 必须重启的参数，先用
mysqladmin shutdown，再用mysqld --defaults-file=/path/to/my.cnf --skip-grant-tables试启，避免配置错误导致无法启动
真正难的不是改配置，是厘清“谁有权限改、改了影响谁、改完怎么验证”。文件权限、启动路径、动态变量作用域这三块漏掉任何一环，审计就形同虚设。
