mysql安全加固需改root密码、禁空密、设密码策略、禁远程root、建最小权限账号、禁用危险功能、审计日志，并执行alter user、drop user、grant等命令后flush privileges生效。
不要把数据库密码硬编码进应用配置文件，这是最直接、最危险的错误做法。 MySQL本身不管理应用层的密码存储，它的职责是验证连接请求；真正需要你动手加固的是应用启动时如何安全传递和使用密码。
为什么 config.yml 里写 password: 'xxx' 是高危操作
这类配置一旦被提交到 Git、上传到容器镜像、或被日志打印，密码就等同于明文暴露。MySQL 服务端无法阻止这种行为，它只负责接收并校验——哪怕密码是从环境变量、Vault 或密钥管理服务动态注入的，只要最终以明文形式出现在连接字符串中（如 mysql://user:pass@host/db），风险就依然存在。
- CI/CD 流水线日志可能意外记录完整连接串
- Docker inspect 或 kubectl get pod -o yaml 可能暴露环境变量值
- Java 应用若启用了 JMX 或 actuator/env 端点，
spring.datasource.password可能被直接返回 - MySQL 的
processlist不显示密码，但应用进程内存 dump 仍可能提取出明文凭据
推荐的三类安全注入方式（按优先级排序）
核心原则：让密码在运行时才解密/获取，且不落地、不日志、不透出。
-
环境变量 + 启动时注入：最轻量，适用于 Docker/K8s。启动容器时用
--env MYSQL_PASSWORD_FILE=/run/secrets/db_pass或 K8ssecretKeyRef挂载文件，应用读取该文件内容作为密码。注意：MYSQL_PASSWORD这类变量名本身不能出现在ps aux输出中（某些语言 runtime 会过滤，但非全部） -
Secrets Manager 集成（如 HashiCorp Vault、AWS Secrets Manager）：应用启动时调用 Vault API 获取 token，再用 token 换取短期有效的数据库凭据。需配置 TTL 和 renew 逻辑，避免长期凭证泄露。MySQL 侧需配合使用
caching_sha2_password插件，支持频繁轮换 - 代理层凭据中转（如 mysql-router、ProxySQL）：应用连接本地代理，代理负责向 MySQL 转发请求并代填真实密码。好处是应用完全不接触密码；缺点是引入新组件，且代理自身密码仍需保护
MySQL 侧必须同步做的两件事
即使应用层做了严密防护，MySQL 服务端配置不当也会让努力白费。
- 禁用
mysql_native_password插件（尤其在 MySQL 8.0+）：ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'xxx';—— 它支持更安全的握手流程，防止中间人截获哈希挑战响应 - 限制用户来源主机：
CREATE USER 'app_user'@'10.20.30.%' IDENTIFIED BY 'xxx';，避免用'%'开放所有 IP；生产环境应结合网络策略（如 Security Group、iptables）做双重限制 - 关闭
secure_file_priv或设为NULL（除非真需要 LOAD DATA）：防止攻击者通过 SQL 注入触发文件读取，进而窃取配置文件中的密码
最容易被忽略的一点：应用连接池（如 HikariCP、Druid）的 password 属性如果被 Spring Boot 的 /actuator/env 或 Micrometer 暴露，会导致密码随指标一起上报。必须显式配置 management.endpoint.env.show-values=NEVER 并禁用敏感属性自动绑定。
