MySQL创建限定IP用户需显式指定host（如'192.168.1.100'或'10.0.2.%'），避免默认'%';授权后必须执行FLUSH PRIVILEGES;注意'localhost'与'127.0.0.1'是不同账号；还需检查防火墙和bind_address配置。
MySQL创建限定IP的用户要指定host参数
MySQL用户账号由username@host共同构成，其中host部分决定该用户能从哪些IP或主机连接。不显式指定host（比如只写CREATE USER 'u1'）默认等价于'u1'@'%'，即允许任意IP连接——这是最常见误操作。
正确做法是在创建时直接写死IP或网段：
CREATE USER 'app_user'@'192.168.1.100' IDENTIFIED BY 'strong_pass_2024';
如果应用服务器是固定内网IP，就填那个IP；如果是云上ECS且IP可能变化，可考虑用CIDR网段，例如：
CREATE USER 'app_user'@'10.0.2.%' IDENTIFIED BY 'strong_pass_2024';
-
10.0.2.%匹配10.0.2.0–10.0.2.255所有地址，但不匹配10.0.20.5 - MySQL不支持标准CIDR写法如
10.0.2.0/24，只能用%或_通配符 - 若需精确匹配IPv6地址，必须用方括号包裹，例如
'user'@'2001:db8::1'
授权后必须执行FLUSH PRIVILEGES
创建用户只是第一步，CREATE USER本身不赋予任何权限。即使后续执行了GRANT，MySQL也不会立即生效，因为权限缓存在内存中。
务必在GRANT之后运行：
FLUSH PRIVILEGES;
否则新用户会报错Access denied for user，哪怕用户名密码和IP都对。这个步骤不能省，也不能靠重启MySQL代替——重启虽有效，但不必要且影响服务。
典型完整流程：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
CREATE USER 'api_db'@'172.16.5.22' IDENTIFIED BY 'xK9#qL2m';<br>GRANT SELECT, INSERT ON myapp.* TO 'api_db'@'172.16.5.22';<br>FLUSH PRIVILEGES;
localhost和127.0.0.1不是一回事
很多开发者以为'user'@'localhost'和'user'@'127.0.0.1'等价，其实它们在MySQL中是两个完全独立的账号，行为也不同：
-
'user'@'localhost'强制走Unix socket连接（跳过TCP/IP栈），无法远程访问 -
'user'@'127.0.0.1'走TCP/IP，可通过本地回环访问，也能被远程IP伪装绕过（如果防火墙没拦） - 如果测试时用
mysql -u user -p能连，但程序用127.0.0.1连失败，大概率是因为只建了@'localhost'账号
线上部署建议避开localhost，统一用具体IP或127.0.0.1，避免连接方式歧义。
防火墙和MySQL bind-address会双重拦截
即使MySQL里限制了'user'@'192.168.3.4'，如果服务器防火墙（如iptables、ufw）没放行3306端口，或者MySQL配置了bind_address = 127.0.0.1，外部IP根本连不到MySQL进程，自然验证不到用户规则。
检查点清单：
- 确认
netstat -tlnp | grep :3306显示监听的是*:3306或对应网卡IP，而非仅127.0.0.1:3306 - 确认防火墙允许目标IP访问3306，例如：
ufw allow from 192.168.3.4 to any port 3306 - 确认客户端实际发起连接的源IP确实是白名单里的那个——NAT、代理、负载均衡器可能隐藏真实IP
IP限制看似简单，但MySQL权限层、网络栈、防火墙三层叠加，任一环节出问题都会表现为“用户不存在”或“拒绝访问”，排查时得一层层剥开看。
