MySQL 修改 my.cnf 不生效？配置檔讀取優先級與多實例管理最佳實踐

MySQL 修改 my.cnf 不生效？配置檔讀取優先級與多實例管理最佳實踐

問題現象

修改 my.cnf 後重啟服務，配置卻未生效。核心原因：修改的不是 MySQL 實際讀取的配置檔。

MySQL 配置檔讀取優先級順序

1. /etc/my.cnf (全域系統級)
2. /etc/mysql/my.cnf (Debian/Ubuntu 系統級)
3. /usr/local/mysql/etc/my.cnf (編譯安裝預設)
4. ~/.my.cnf (用戶級，僅影響當前用戶客戶端)
5. 自定義路徑 (如 /data/mysql/3306/my.cnf)

後讀取的配置會覆蓋先讀取的同名參數。

強制指定配置檔的兩種方式

# 1. 僅讀取指定檔 (忽略所有其他配置檔)
--defaults-file=/path/to/my.cnf

# 2. 先讀取高優先級全域配置，再讀取指定檔覆蓋
--defaults-extra-file=/path/to/my.cnf

多實例管理最佳實踐

建議統一將所有實例配置集中管理於 /etc/my.cnf，採用 !includedir 或多實例區段：

[mysqld_3306]
port=3306
datadir=/data/mysql/3306/data
socket=/tmp/mysql3306.sock
...

[mysqld_3307]
port=3307
datadir=/data/mysql/3307/data
socket=/tmp/mysql3307.sock
...

啟動時指定 --defaults-file=/etc/my.cnf --defaults-group-suffix=_3306。

排查清單

1. 確認修改的檔案路徑是否為實際生效路徑 (mysql --help | grep my.cnf)
2. 檢查是否有語法錯誤 (如缺少區段標題 [mysqld])
3. 參數名稱拼寫是否正確 (如 innodb_buffer_pool_size 非 innodb_buffer_pool)
4. 重啟方式是否正確 (systemctl vs mysqld_safe vs init.d)