应避免明文密码暴露：交互式输入密码、使用权限为600的~/.my.cnf配置文件、代码中通过环境变量获取密码、应用账号遵循最小权限原则、强制ssl加密连接。
MySQL 连接时密码明文暴露在命令行里怎么办
直接用 mysql -u root -p123456 这种方式，密码会留在 shell 历史、进程列表、审计日志里，谁都能看到。这不是“不安全”，是“已经泄露”。
改用交互式输密码：去掉 -p 后面的值，执行 mysql -u root -p，回车后单独输入——这时密码不会进历史、也不会出现在 ps aux 输出中。
更稳妥的做法是用配置文件 + 权限控制：
- 新建
~/.my.cnf，写入[client]段，加user=root和password=xxx - 立刻执行
chmod 600 ~/.my.cnf，否则 MySQL 客户端会拒绝读取 - 注意：该文件只对当前用户生效，且不能被组/其他用户读取，否则报错
File '/home/u/.my.cnf' contains options starting with 'password' but is not owned by current user or has wrong permissions
应用代码里硬编码数据库密码怎么替换
把密码写死在 Python 的 conn = pymysql.connect(password='xxx') 或 Java 的 JDBC URL 里，等于把钥匙贴在门上。不是“可能泄露”，是只要源码或包被拿到就立刻失效。
优先走环境变量，而不是配置文件：
- 启动前设
export DB_PASSWORD=xxx，代码里用os.getenv('DB_PASSWORD')（Python）或System.getenv("DB_PASSWORD")（Java） - 避免把密码塞进 Git —— 即使 .gitignore 了配置文件，也常有人误提交
.env或临时测试脚本 - 如果必须用配置文件（如 Spring Boot 的
application.yml），确保它不在版本控制中，并用spring.config.import=optional:file:./config/db.yml隔离加载路径
MySQL 用户权限配得太宽导致越权访问
给应用账号授 GRANT ALL PRIVILEGES ON *.* TO 'app'，相当于给前台收银员一把公司保险柜总钥匙。一旦账号泄漏或 SQL 注入得手，整库可删可拖。
最小权限原则不是口号，是必须落地的操作：
- 只授权具体库：
GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'app'@'10.10.1.%' - 禁止远程 root 登录：
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost'; FLUSH PRIVILEGES; - 敏感操作（如
DROP TABLE、CREATE USER）一律不放给应用账号，运维走专用跳板机+临时提权流程
顺带一提：SHOW GRANTS FOR 'app'@'%' 要定期查，别信“当初配过就没动过”。
连接加密没开，密码和数据都在裸奔
默认 MySQL 连接是明文传输，中间人能抓包看到完整 SQL 和返回结果，包括 SELECT password FROM users 这种语句——哪怕密码字段本身是哈希过的，查询行为本身也暴露业务逻辑。
强制 SSL 不只是加个参数的事：
- 服务端先确认
have_ssl是YES：SHOW VARIABLES LIKE 'have_ssl'; - 创建用户时指定
REQUIRE SSL：CREATE USER 'app'@'%' IDENTIFIED BY 'x' REQUIRE SSL; - 客户端连接必须显式启用，比如 Python 里
pymysql.connect(..., ssl={'ca': '/path/to/ca.pem'})；只设ssl=True不够，没 CA 校验等于形同虚设
真正麻烦的是内网服务之间互相调用——很多人以为“内网不用 SSL”，但容器网络、云 VPC 并不天然可信，只要没做网络策略隔离，抓包成本极低。
