今天接到通知，有专家将对公司的X 项目进行检查 ， X 项目的数据库 是MYSQL 5.7.24 版本的 ， 不知道为什总是频繁的异常重启。
项目上的小伙伴为了保证系统的稳定，决定将后台切换的 MYSQL 5.7.25 版本的数据库去运行。
但切换数据库后出现了 ORDER BY clause is not in SELECT list 这一 SQL 报错 ， 项目上的小伙伴不知道具体的发生原因，遂切回原来的 5.7.24 版本的数据库
但报错信息依旧存在 ,百度查得 这一错误是应为MYSQL 5.7 默认启用了 ONLY_FULL_GROUP_BY 配置导致的 , 于是小伙伴修改了 /etc/my.cnf 并重启 MYSQL，但报错信息依旧存在。
被找到的时候，其实我也很迷茫。 因为 /etc/my.cnf 我看过了 ， 没有问题啊 。 而且配置文件是 公司自动化部署脚本自动部署的 ， 为什么其他项目可以正常使用 ，但是 X 项目就不行了呢？
由于事情紧急,使用 ROOT 账号登录到数据库 ， 使用 select @@global.sql_mode; 查到，当前MYSQL 确实开启了 ONLY_FULL_GROUP_BY 功能 ， 这就很奇怪了 ...
使用 set @@global.sql_mode ='' 临时修改了MYSQL 的全局配置 ， 项目正常运行
晚上闲下来的时候就在想 ，为什么 /etc/my.cnf 的配置不生效呢
百度了一下，通过 /usr/local/mysql/bin/mysqld --verbose --help |grep -A 1 'Default options' 查看当前MYSQL 的 配置文件
结果看到了这样的回显
本来按照[Warning] = [OK] 的习惯，我直接忽视了这个报警，那么 现在MYSQL 到底使用了那个配置文件呢？
我一路 cat 下去
发现系统中除了 /etc/my.cnf 以外其他配置文件都不存在。
这...,仔细看看[Warning]消息。在 ll 一下 /etc/my.cnf , 我明白问题的关键了
因为系统中的/etc/my.cnf 被赋予了 777 权限 ， MYSQL 任务该文件是任意用户可读的不安全文件，所以自动忽略了这个配置文件，又因为没有其他配置文件，所以 MYSQL 使用默认配置启动
chmod 644 /etc/my.cnf 并重启MYSQL ， 查得问题解决，配置文件生效。