MySQL 密碼安全輸入完整指南：四種方式風險分析與最佳實踐

編輯：MySQL 資料庫相關知識

連線 MySQL 時密碼若在命令列明文出現，會被 ps、歷史檔、程序檢視器洩露。本文詳細分析四種輸入方式的風險等級，並給出生產環境最佳實踐建議。

四種密碼輸入方式風險對比

方式	指令範例	風險等級	風險說明
1. 命令列明文	`mysql -u root -pmypassword db` `mysql -u root --password=mypassword db`	🔴 極高	`ps -ef` 可見參數；雖客戶端啟動後會嘗試覆蓋 argv，但仍有時間窗口洩露。背景執行 `&` 更易被 `ps` 捕獲。
2. 互動式提示	`mysql -u root -p db` → `Enter password: *********`	🟢 低	密碼不顯示於命令列、不寫入歷史檔。但僅適用互動式終端，腳本/自動化無法使用。
3. 設定檔	`~/.my.cnf` (Linux) `[client] password=your_pass`	🟡 中 (視權限)	檔案權限必須 `chmod 600` (僅擁有者讀寫)。MySQL 會忽略群組/他人可寫的設定檔。Windows 用 `%APPDATA%\MySQL\.my.cnf`。
4. 環境變數	`export MYSQL_PWD=your_pass`	🔴 極高	`ps e` 可見所有進程環境變數；任何同機使用者皆可讀取。官方強烈不建議使用。

建立/編輯 ~/.my.cnf：

[client]
user=your_user
password=your_strong_password
host=127.0.0.1
port=3306

MySQL 讀取設定檔順序：/etc/my.cnf → /etc/mysql/my.cnf → ~/.my.cnf → --defaults-extra-file。後讀取者優先覆蓋。

MySQL 客戶端歷史檔：~/.mysql_history 會記錄 CREATE USER、GRANT、SET PASSWORD 等含密碼指令。
→ 設定 chmod 600 ~/.mysql_history 或定期清空，或設定 MYSQL_HISTFILE=/dev/null 禁用。
Shell 歷史檔：~/.bash_history 等會記錄命令列密碼。
→ 避免命令列帶密碼；或設定 HISTCONTROL=ignorespace，命令前加空格不記錄。
一般查詢日誌：若開啟 general_log，SQL 含密碼會寫入日誌。
→ 生產環境關閉 general_log，或啟用 log-raw=OFF (8.0+) 脫敏。

Docker Secrets / Kubernetes Secrets：密碼掛載為檔案 /run/secrets/mysql_password，啟動腳本讀取：
PASSWORD=$(cat /run/secrets/mysql_password)
mysql -u root -p"$PASSWORD" (參數展開在程序建立後，ps 不見明文)。
配置管理工具：Ansible Vault、HashiCorp Vault、AWS Secrets Manager 運行時注入。
MySQL 8.0 密碼插件：caching_sha2_password 配合 TLS，避免明文傳輸。