MySQL安全配置需立即修改默认root密码、禁用匿名及远程root用户、启用密码强度插件；绑定本地地址、限制连接数与超时时间；强制开启严格SQL模式与InnoDB严格模式，确保数据一致性与连接稳定性。
MySQL 实例默认账户与密码策略必须改
新部署的 MySQL 实例默认存在 root@localhost 账户，且部分版本（如某些 Docker 镜像或一键安装包）会设为空密码或弱密码。这等于把数据库大门敞开在公网或内网任意节点前。
实操建议：
- 首次登录后立即执行
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '强密码';，避免使用SET PASSWORD（已弃用） - 删除匿名用户：
DROP USER ''@'localhost'; - 禁用远程 root 登录：
DROP USER 'root'@'%';，如需远程管理，单独创建带 IP 限制和最小权限的专用账户 - 启用密码强度插件：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';<br>SET GLOBAL validate_password.policy = MEDIUM;
，否则validate_password.length等参数不生效
bind-address 和 skip-networking 决定网络暴露面
bind-address 配置错误是导致 MySQL 意外暴露在公网的最常见原因。默认值 127.0.0.1 仅监听本地，但若被改成 0.0.0.0 或注释掉，又没配防火墙，实例就直接裸奔。
实操建议：
- 生产环境必须显式设置
bind-address = 127.0.0.1，除非明确需要跨主机访问 - 如果应用与 MySQL 同机部署，可进一步关闭 TCP 协议，只走 socket：
skip-networking = ON（注意：该选项与bind-address互斥，开启后bind-address失效） - 确认生效：执行
SHOW VARIABLES LIKE 'bind_address';和netstat -tlnp | grep :3306，检查监听地址是否符合预期
max_connections 和 wait_timeout 直接影响连接稳定性
默认 max_connections = 151 在高并发场景下极易打满，而过长的 wait_timeout（默认 28800 秒）会导致大量空闲连接堆积，占用内存并拖慢新连接建立。
实操建议：
- 根据实际连接池大小预估并发量，设为
max_connections = 500左右较稳妥；超过 1000 需同步调大open_files_limit和系统级ulimit -n -
wait_timeout和interactive_timeout建议统一设为300（5 分钟），避免连接长期空转 - 监控活跃连接数：
SHOW STATUS LIKE 'Threads_connected';，持续接近max_connections就要查应用是否漏关连接或连接池配置不合理
sql_mode 和 innodb_strict_mode 关系数据一致性
默认 sql_mode 包含 STRICT_TRANS_TABLES 的版本较少（如 MySQL 5.7 默认不含，8.0 才默认开启），而 innodb_strict_mode = OFF 会让 InnoDB 忽略字段长度超限、零日期等错误，静默截断或转成默认值，埋下数据质量隐患。
实操建议：
- 在
my.cnf中强制启用严格模式：sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"<br>innodb_strict_mode = ON
- 修改后重启实例，并用
SELECT @@sql_mode;和SELECT @@innodb_strict_mode;双重验证 - 上线前务必在测试库执行全量 DML 回放，防止历史 SQL 因严格模式报错中断
安全配置不是一次性开关，而是和应用连接行为、监控告警、定期审计绑定在一起的动作。最容易被忽略的是 wait_timeout 和连接池 idle timeout 的配合——两者不一致时，连接池认为连接还活着，MySQL 却已主动断开，结果就是应用层报 MySQL server has gone away。
