用户权限这块很多人图省事，直接给个root权限满世界跑。你知道MySQL里光用户权限就有几十种吗？SELECT/INSERT这些基础权限不说，PROCESS权限能看当前连接，FILE权限能读写服务器文件。上次见过有个开发把FILE权限给了应用账户，结果被注入攻击直接拖走了整个/etc/passwd。建议遵循最小权限原则，像网站应用账户顶多给个库级别的增删改查，千万别跨库授权。
密码策略现在MySQL8.0已经支持密码验证组件了，可以强制要求大小写混合+特殊字符。老版本也别慌，在my.cnf里加上validate_password参数就行。见过最绝的配置是要求30天改密码，连续错5次就锁账户，虽然运维同事天天骂娘，但确实防住了暴力破解。
网络配置里有个特别容易踩的坑------bind-address参数。有些人为方便直接设成0.0.0.0，这不就等于在服务器门口挂欢迎光临的牌子吗？正经做法应该是内网IP+防火墙白名单。云服务器更得注意，别以为放在VPC里就安全，去年某公司就是因为数据库端口对公网开放，被勒索软件加密了核心业务表。
传输加密这块现在TLS已经是标配了，但证书配置经常出幺蛾子。自己签的证书记得把CA参数设对，不然客户端连不上还以为是防火墙问题。曾经帮人排查过两个小时连接超时，最后发现是证书有效期设到了2020年。
SQL注入老生常谈，但总有人觉得用框架就万事大吉。去年我们遇到个奇葩案例，攻击者通过JSON字段注入执行了LOAD DATA LOCAL INFILE，把服务器文件都扒走了。建议开启sql_mode的严格模式，特别是ONLY_FULL_GROUP_BY和STRICT_TRANS_TABLES这两个参数，能拦下不少畸形查询。
审计功能企业版要收费，社区版可以用通用日志或者慢查询日志凑合。有个取巧的办法是定期跑mysqlbinlog解析二进制日志，配合grep抓敏感操作。见过某金融公司自己写触发器记录每张表的变更，虽然性能掉百分之十，但合规检查时真能救命。
备份策略很多人只知道mysqldump，其实xtrabackup做物理备份才叫快。关键是要验证备份文件能不能正常还原，我每月都会在测试环境做次灾难恢复演练。有次生产库硬盘故障，靠着一周前的全量备份+实时binlog，最后只丢了2分钟数据。
最近在研究MySQL企业版的数据脱敏功能，发现用虚拟列也能实现类似效果。比如把手机号中间四位用星号替换，既满足业务查询又避免隐私泄露。不过要注意虚拟列不能建索引，大数据量查询还是得想别的招。
说到底数据库安全就是个持续过程，去年爆出的CVE-2022-2124漏洞让多少没及时打补丁的企业吃了亏。建议定个季度安全巡检清单，从用户权限到日志轮询全部过一遍。毕竟数据这玩意儿，丢了再找回来可比防患于未然费劲多了。