必须立即删除test库和匿名用户，这是mysql安全第一道铁闸；执行drop database if exists test;和delete from mysql.user where user='';并强制flush privileges;刷新权限。
生产环境 MySQL 数据安全不能靠“差不多就行”，必须从账号、网络、加密、备份四个硬性切口同时卡死。任何一环松动，都可能让一次误操作或一次扫描直接击穿整套防护。
删掉 test 库和匿名用户是第一道铁闸
默认安装的 test 数据库和空用户名账号（User=''）不是“留着无害”，而是明摆着的后门。攻击者连密码都不用猜，只要能连上 MySQL 就能读写 test，再通过它触发 UDF 或利用本地文件读取能力横向渗透。
- 立刻执行：
DROP DATABASE IF EXISTS test;和DELETE FROM mysql.user WHERE User=''; - 别信“我只开内网”，只要端口暴露在容器网段或 Kubernetes Service 中，就等于暴露给整个集群内的任意 Pod
- 执行完必须
FLUSH PRIVILEGES;，否则权限表缓存不刷新，删了也白删
应用账号必须限定 IP + 最小权限 + SSL 强制
用 app_user@'%' 这种通配符账号配生产服务，等于把数据库大门钥匙挂在 API 网关的请求头里。哪怕你做了 WAF，SQL 注入一旦绕过，DROP TABLE 就是一条语句的事。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- IP 范围要精确到子网，比如
app_user@'10.10.5.0/24'，而不是'%'；云环境优先用 VPC 内网 CIDR，别用公网 NAT IP - 权限只给
SELECT, INSERT, UPDATE，明确排除DELETE, DROP, ALTER, CREATE—— 删除逻辑应由应用层软删字段控制 - 强制 SSL：
GRANT SELECT ON order_db.* TO 'app_user'@'10.10.5.%' REQUIRE SSL;，并确认客户端连接字符串含?ssl-mode=REQUIRED
备份不是“有就行”，而是“随时可验证还原”
很多团队的备份脚本跑 cron 成功了就以为万事大吉，直到恢复时发现 mysqldump 没加 --single-transaction 导致主从延迟飙升，或 xtrabackup 备份集没做 --apply-log 根本起不来。
- 全量备份必须包含
--routines --triggers --events，否则存储过程和事件调度器丢失，业务逻辑断裂 - 每天至少一次恢复演练：拉一个临时实例，用最近备份 + binlog 回放到故障前 1 分钟，记录耗时
- 备份文件本身要加密：
gpg --cipher-algo AES256 --symmetric backup.sql.gz，密钥单独保管，不跟备份同盘
SSL/TLS 不是选配，是等保三级刚性要求
未启用 SSL 的 MySQL 流量，在交换机镜像、宿主机抓包、甚至同节点其他容器里，都能被明文截获。等保测评中这一项不通过，整套系统直接卡在“基本要求”门槛外。
- 证书不能用自签名应付事：必须用 OpenSSL 生成带 SAN 的证书，且
subjectAltName包含所有允许连接的域名/IP - 配置后务必验证：
mysql -u app_user -p --ssl-mode=REQUIRED -h db.example.com，失败则检查require_secure_transport=ON是否生效 - 禁用旧协议：
tls_version = TLSv1.2,TLSv1.3，MySQL 8.0.28+ 支持，别留 TLSv1.0 这种裸奔通道
真正难的不是某一条命令怎么写，而是每次上线新服务时，是否坚持走完账号创建 → 权限回收 → 备份接入 → SSL 验证这四步闭环。漏掉任意一步，防线就出现肉眼不可见的裂缝。
