创建用户时直接指定允许连接的IP地址
MySQL 用户账号由
username@host组成，其中
host部分决定该用户能从哪些主机连接。这不是事后配置项，而是创建时就定死的权限边界。
host填
'192.168.1.100'：仅允许该IP连接 填
'192.168.1.%'：匹配 C 类网段内任意 IP（注意是 MySQL 自己的通配符规则，不是正则） 填
'localhost'：仅限本机 Unix socket 或 127.0.0.1（取决于连接方式），和
'127.0.0.1'实际行为不同 填
'%'：允许任意 IP 连接（最危险，生产环境应避免）
示例：
CREATE USER 'appuser'@'10.20.30.40' IDENTIFIED BY 'strongpass123';这条命令生成的用户，即使你后续执行
GRANT ALL ON *.* TO 'appuser'@'%'，也不会生效——因为
'appuser'@'%'是另一个完全不同的账号。
修改已有用户的 host 部分不能用 ALTER USER
ALTER USER无法修改用户名或 host，它只改密码、过期策略、资源限制等。想换绑定 IP，必须删旧建新。 先查清楚当前账号全名：
SELECT User, Host FROM mysql.user WHERE User = 'appuser';删除旧账号：
DROP USER 'appuser'@'%' ;再重建带限定 IP 的账号：
CREATE USER 'appuser'@'10.20.30.40' IDENTIFIED BY 'newpass';最后赋权：
GRANT SELECT, INSERT ON mydb.* TO 'appuser'@'10.20.30.40';别忘了
FLUSH PRIVILEGES;（虽然 8.0+ 多数情况自动刷新，但显式执行更稳妥）
漏掉
DROP USER直接
CREATE USER会报错
ERROR 1396 (HY000): Operation CREATE USER failed for 'appuser'@'%'，因为同名账号已存在。
防火墙与 bind-address 是双重保险，但作用层次不同
MySQL 层面的
host限制是认证前检查，属于逻辑访问控制；而系统层防火墙（如 iptables / ufw）和 MySQL 的
bind-address配置是网络层拦截。
bind-address = 127.0.0.1：MySQL 只监听本地回环，外部 IP 根本连不上 TCP 端口，
'user'@'%'也无效
bind-address = 0.0.0.0或注释掉：监听所有接口，此时才轮到 MySQL 检查账号的
host字段 防火墙规则（如
ufw allow from 10.20.30.40 to any port 3306）在连接到达 MySQL 前就丢包，不消耗 MySQL 连接数，也不留登录失败日志
三者不是替代关系，而是叠加生效。线上建议至少启用其中两层，尤其不要依赖单一的
host限制。
客户端连接失败时，先看错误信息再排查
常见报错和对应方向：
ERROR 1045 (28000): Access denied for user 'u'@'192.168.1.200'：账号存在，但密码错或权限不足，
host匹配成功
ERROR 1130 (HY000): Host '192.168.1.200' is not allowed to connect to this MySQL server：MySQL 找不到
'u'@'192.168.1.200'或
'u'@'%'这样的账号，
host不匹配 连接超时（无 ERROR）：大概率是防火墙拦截或
bind-address未开放对应网卡
用
mysql -h 10.20.30.40 -u appuser -p测试时，如果服务器端
SHOW PROCESSLIST;看不到该连接，基本可判定卡在网络层。
真正容易被忽略的是：MySQL 的
host匹配是精确字符串比较，不解析 DNS；如果你在创建用户时用了域名（如
'user'@'web1.example.com'），而客户端反向解析出的 hostname 不一致，就会匹配失败。生产环境一律用 IP，别碰域名。
