MySQL的权限系统里藏着个反直觉的设计——IP限制不是写在配置文件里的，而是挂在用户账号上的。这事儿我踩过坑。有次给客户做等保测评，对方数据库管理员信誓旦旦说“已经限制了远程访问”，结果我拿手机热点一连，3306端口照样通。他压根没动过`mysql.user`表，只在防火墙层面做了手脚。 真正限制IP访问，核心就一句话：**改账号的host字段**。MySQL安装完默认有个`root@localhost`，但很多人图省事会创建`root@'%'`这种万能账号。`%`代表任意IP，等于把数据库裸奔在公网上。正确做法是`CREATE USER 'app'@'192.168.1.100' IDENTIFIED BY '强密码'`，或者直接改现有账号：`UPDATE mysql.user SET host='192.168.1.100' WHERE user='app';`改完记得`FLUSH PRIVILEGES`。 这里有个容易被忽略的细节——MySQL匹配host规则是“最具体优先”。比如同时存在`'app'@'%'`和`'app'@'192.168.1.%'`，你从192.168.1.50登录时，MySQL会挑第二个，而不是第一个。这导致一种隐蔽风险：你以为删了`'%'`账号就安全了，实际上残留的网段账号还在偷偷生效。我见过生产环境就这么被拖库的，排查时发现有个老同事五年前建的`'backup'@'10.0.%'`账号，密码还是弱口令。 日常运维中，最实用的限制策略分三层。第一层，本地访问只留`localhost`和`127.0.0.1`，应用服务器走内网IP段，比如`'web'@'172.16.8.%'`。第二层，开发环境单独建账号，host限定公司出口IP或VPN网段。第三层，所有账号禁用`'%'`，万一真需要动态IP访问，用`'user'@'203.0.113.0/24'`这种CIDR写法，MySQL 8.0支持。 有人会问，那我用防火墙限制不也一样？不一样。防火墙拦的是TCP层，MySQL权限拦的是应用层。数据库直连绕过防火墙的情况太多了——比如内网跳板机被攻破，或者云厂商的安全组规则配错。MySQL自身的host限制是最后一道防线，这层守住，至少攻击者拿到账号密码也连不上。 再补个冷门但实用的操作——查看当前所有账号的host分布：`SELECT user, host FROM mysql.user;`。我习惯每周跑一次这命令，配合`information_schema.PROCESSLIST`看实时连接来源。上个月还真发现个异常，有个测试库的账号host被改成了`'%'`，查下来是某同事为了在家调试临时改的，改完忘还原。这破事没人说，但审计记录里清清楚楚。 最后提醒一句，改完host后别急着庆祝，先测试一下。用`mysql -h 目标IP -u 账号 -p`从允许的IP连一次，再从禁止的IP连一次，确认后者报`Host is not allowed to connect`。这错误信息本身就是最好的验证报告。