SQL用户密码严禁明文存储，须用环境变量注入并升级客户端驱动；MySQL 8.0+认证插件需兼容配置；轮换密码须同步刷新连接池；数据库认证必须由MySQL自身管理，业务密码才可哈希。
SQL 用户密码明文存储直接暴露风险
数据库用户密码绝不能以明文形式写在配置文件、连接字符串或应用代码里。一旦源码泄露、服务器被入侵或日志意外输出，PASSWORD='123456' 这类内容会立刻成为攻击入口。
常见错误现象：mysql -u root -p123456 直接带密码执行；Docker Compose 中 MYSQL_ROOT_PASSWORD: "abc123" 硬编码；Spring Boot 的 spring.datasource.password=secret 提交到 Git。
- 改用环境变量注入：启动时通过
MYSQL_ROOT_PASSWORD或DATABASE_PASSWORD传入，宿主机或 CI/CD 环境中设为 secret - 连接字符串中去掉密码字段，改由驱动从环境变量或凭据提供者读取（如 Java 的
DataSource配合HikariCP的dataSourceProperties） - 禁止在 SQL 脚本、迁移工具（如 Flyway/Liquibase）的配置中写死密码；改用
flyway.placeholders.password=${DB_PASSWORD}+ 外部注入
MySQL 8.0+ 默认认证插件不兼容旧客户端
MySQL 8.0 默认使用 caching_sha2_password 插件，而很多老版本 JDBC 驱动（mysql-connector-java ）、PHP <code>mysqli 或命令行客户端未启用对应支持，会导致“Access denied for user”或“Client does not support authentication protocol”错误。
这不是密码错了，是握手协议不匹配。强行重置密码或降级插件可能掩盖问题，但破坏安全基线。
- 优先升级客户端驱动：Java 项目确保
mysql-connector-java≥8.0.28，并显式指定serverTimezone和allowPublicKeyRetrieval=true（仅调试期，生产应配 RSA 密钥） - 若必须兼容旧客户端，创建用户时指定插件：
CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 避免全局改
default_authentication_plugin，它影响所有新建用户，且削弱默认安全强度
定期轮换密码但忽略连接池缓存残留
密码轮换后，应用没重启，连接池（如 HikariCP、Druid）仍持有一批用旧密码建立的活跃连接，短期内看似正常，但新连接失败、连接泄漏、超时堆积会陆续爆发。
这不是数据库没生效，是客户端侧状态没刷新。尤其在 Kubernetes 中滚动更新未触发连接池重建，问题更隐蔽。
- 轮换前先调用连接池的
evict()或close()（如 HikariCP 的HikariDataSource#close()），再重建 DataSource - 设置连接测试语句（
connection-test-query=SELECT 1）和验证间隔（validation-timeout），让失效连接尽快被剔除 - 避免依赖“连接空闲自动断开”——MySQL 的
wait_timeout默认 8 小时，远长于密码策略要求的轮换周期
用 Hashed password 替代明文校验的陷阱
有人试图把密码哈希后存进数据库字段，登录时比对哈希值。这完全违背 SQL 用户认证机制：MySQL 不校验你表里的 password_hash 字段，它只认 mysql.user 表中由 ALTER USER ... IDENTIFIED BY 设置的内部凭证。
这类做法实际构建了一套自研鉴权层，却误以为在加固数据库本身，反而绕过 MySQL 的密码复杂度策略、失败锁定、TLS 强制等内置防护。
- 数据库用户密码必须由 MySQL 自身管理，用
ALTER USER 'u'@'h' IDENTIFIED BY 'newpwd'修改 - 业务层密码（如用户登录表）才适合用 bcrypt/scrypt/PBKDF2 哈希，且必须配合盐值与防爆破机制
- 不要在应用里拼接
SELECT * FROM users WHERE username=? AND password=SHA2(?,256)—— 这既不安全也不符合最小权限原则
真正难的不是换密码，是让每次密码变更都同步穿透到连接池、监控告警、审计日志、跨集群副本、以及开发本地调试环境——这些点漏掉一个，安全策略就断一环。
