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。
