别让数据库裸奔，MySQL安全防护实战指南

这事儿别等中招了才后悔

说实话，做开发的谁没经历过半夜被电话叫醒查日志的绝望？尤其是数据库这玩意儿，一旦被拖库或者勒索，那感觉就像自家大门敞开，小偷不仅把东西搬空，还在客厅留张嘲讽纸条。MySQL 虽好，但如果你默认安装完就直接用，那基本就是在互联网上裸奔。今天咱们不整那些虚头巴脑的理论，就聊聊老手们都是怎么给数据库穿防弹衣的。

账号权限：别把核按钮交给实习生

很多人为了省事，线上业务居然直接用 root 账号跑，这简直是在雷区蹦迪。你想想，要是代码有个 SQL 注入漏洞，黑客拿 root 权限干啥都行，甚至还能直接关机。这事儿吧，原则就一条：最小权限原则。

别再偷懒了，给每个应用建单独的账号，只给它必须要的权限。比如读业务的账号，就只给 SELECT 权限；写业务的，加个 INSERT、UPDATE 也就够了。千万别给 ALL PRIVILEGES，除非你真的想体验一把心跳骤停的感觉。

```sql -- 只给查的权限，够用就行 GRANT SELECT ON app_db. TO 'readonly_user'@'192.168.1.%'; -- 刷新权限，立刻生效 FLUSH PRIVILEGES; ```

端口管理：别对全世界敞开大门

MySQL 默认的 3306 端口，别再对 0.0.0.0/0 开放了，这等于拿着大喇叭喊“快来黑我”。这就像你家里装了防盗门，结果钥匙就挂在门把手上。正确的姿势是，只监听本地内网 IP，或者干脆只允许应用服务器的 IP 连接。

你有没有发现，绝大多数被黑的数据库都是因为端口没做好限制？改一下配置文件里的 bind-address，只允许内网访问，物理隔绝永远比软件防火墙来得靠谱。如果非得远程管理，请务必用 VPN 跳进去，别直接把端口暴露在公网上，那是给黑客送业绩。

防住老掉牙的 SQL 注入

这都多少年了，SQL 注入依然是 Web 安全头号杀手。说白了，就是没把用户输入当外人。你信了用户的输入，把拼好的 SQL 直接扔给数据库执行，那能不出事吗？

这事儿没得商量，必须用预编译。不管你用 PHP、Java 还是 Python，只要是拼接字符串写 SQL，一律打回重写。预编译就像给输入内容加了个紧箍咒，不管用户输入什么妖魔鬼怪，数据库都把它当纯文本处理，根本没机会执行命令。别嫌麻烦，这一步能救你的命。

```sql -- 错误示范：千万别这么干 String sql = "SELECT FROM users WHERE id = " + userId; -- 正确姿势：使用占位符预编译 String sql = "SELECT FROM users WHERE id = ?"; ```

备份：那是你的后悔药

说句扎心的，没有经过验证的备份，等于没有备份。很多人觉得开了 crontab 定时 mysqldump 就万事大吉了，真到恢复数据的时候才发现，备份文件是空的，或者是损坏的，那时候想死的心都有。

老鸟都知道，备份得玩“3-2-1”策略：至少 3 个副本，2 种不同介质，1 个异地。别把鸡蛋放一个篮子里。而且，一定要定期演练恢复。哪怕你安全做得再好，也防不住 rm -rf 这种手滑操作，或者硬盘突然暴毙的物理伤害。数据丢了，老板可不听你解释什么技术难题，只看结果。

别忽视那些小细节

最后唠叨几句不起眼但致命的坑。默认的 test 数据库，删掉，谁都能进这玩意儿；还有那些空密码的匿名账号，统统清理掉。文件权限也要设好，my.cnf 里别存明文密码，日志文件别包含敏感信息。

安全这事儿吧，不是装个杀毒软件就完事了，它是一种习惯，一种对数据敬畏的态度。把上面这几招练熟了，你的 MySQL 起码能防住 90% 的脚本小子。剩下的 10%，那是攻防博弈的终极战场，咱们以后再细聊。先把地基打牢，别等楼塌了才去修。