MySQL访问控制：GRANT与防火墙的协同策略
MySQL GRANT 语句中指定 IP 时，为什么 localhost 和 127.0.0.1 不等价？
这里有个关键细节常被忽略：MySQL的用户账户其实是一个二元组，由'user'@'host'共同构成。其中，'localhost'是一个特殊标识符，它强制客户端通过Unix socket进行连接，完全绕开TCP/IP协议栈。而'127.0.0.1'则明确指向TCP回环连接。这意味着，如果你创建了用户'app'@'localhost'，那么从本机使用mysql -h 127.0.0.1命令尝试连接时，会直接收到一个Access denied的错误。
所以，当需要精确限制到某个特定IP（例如只允许192.168.10.55访问）时，必须显式地在GRANT语句中声明，写成'app'@'192.168.10.55'。千万别图省事，用'app'@'%'搭配防火墙来“兜底”，这属于典型的权限控制失效，安全隐患极大。
- 首先，用
SELECT User, Host FROM mysql.user;命令确认现有用户的host绑定是否精确匹配目标IP。需要提醒的是，MySQL原生不支持CIDR表示法，只能使用'192.168.10.%'这类SQL通配符。 - 执行授权时，典型的命令如：
GRANT SELECT ON mydb.* TO 'report'@'192.168.10.55' IDENTIFIED BY 'pwd123';。完成后，务必执行FLUSH PRIVILEGES;使权限立即生效。 - 注意版本差异：在MySQL 8.0及以上版本中，默认禁止在GRANT语句中直接使用
IDENTIFIED BY创建用户。正确的做法是先CREATE USER，再执行GRANT授权。
iptables 或 ufw 拦截 MySQL 端口时，为何有时规则不生效？
防火墙规则配置了却不见效？问题往往出在规则顺序错误，或者规则压根没匹配到真实的连接路径。一个常见的盲点是：MySQL服务本身的监听地址。即便MySQL默认监听0.0.0.0:3306，但如果配置文件中设置了bind-address = 127.0.0.1，那么服务实际上只接受本地连接，外部流量根本到不了3306端口，防火墙规则自然也就“英雄无用武之地”了。
因此，第一步永远是先确认MySQL的实际监听状态：
ss -tlnp | grep :3306
如果输出显示127.0.0.1:3306，说明MySQL已自我隔离，无需额外防火墙拦截；只有显示*:3306或0.0.0.0:3306时，才需要防火墙介入管控。
- 使用ufw时，放行特定IP的命令示例：
sudo ufw allow from 192.168.10.55 to any port 3306 - 使用iptables时，命令示例：
sudo iptables -A INPUT -s 192.168.10.55 -p tcp --dport 3306 -j ACCEPT，之后务必追加一条拒绝规则来拦截其余流量。 - 规则顺序是关键！iptables规则是按顺序匹配的，必须确保放行规则在DROP或REJECT规则之前。可以使用
iptables -L --line-numbers来查看和调整顺序。
MySQL 用户 host 字段写 %、192.168.%.% 或子网掩码有什么区别？
MySQL的host字段权限设计有其独特规则。首先，它不支持我们熟悉的子网掩码写法（如192.168.10.0/24），而是采用SQL标准的模式通配符：%匹配任意长度字符串（包括空字符串），_匹配单个字符。
因此，'user'@'192.168.10.%'可以匹配从192.168.10.1到192.168.10.255的所有IP，但无法匹配192.168.11.5。而'user'@'%'则意味着允许来自任何IP地址的连接，包括公网IP，这在生产环境中是极高风险的操作，应极力避免。
- 通配符也支持域名模式，例如
'user'@'%.example.com'可以匹配db.example.com、app.test.example.com等所有子域名，但不会匹配单纯的example.com（因为缺少点号）。 - 需要警惕host为空字符串
''的“匿名用户”，这是极大的安全漏洞。生产环境务必检查并清理：DROP USER ''@'localhost';。 - 对于MySQL 8.0+版本，更推荐使用角色（ROLE）功能进行权限管理：先
CREATE ROLE 'reporter'; GRANT SELECT ON mydb.* TO 'reporter';，再将角色授予具体的用户。这样便于批量管理和维护权限。
应用连接失败时，如何快速区分是权限问题还是网络拦截？
遇到连接故障，别急着翻日志，一个简单的二分法能快速定位方向：先绕过MySQL的权限验证层，直接测试网络连通性。
在客户端机器上，执行telnet 服务器IP 3306或nc -zv 服务器IP 3306。如果连接超时或直接被拒绝，问题大概率出在网络层面（防火墙、MySQL未监听等）。如果命令成功，能看到一些乱码或进入MySQL协议握手阶段，但随后登录失败，那才是经典的Access denied for user权限问题。
- 在服务器端，可以检查几个关键变量：
SHOW VARIABLES LIKE 'skip_networking';如果为ON，MySQL会拒绝所有TCP/IP连接。 - 检查连接数是否已满：
SHOW STATUS LIKE 'Threads_connected';对比max_connections变量。 - 别忘了SELinux：在CentOS或RHEL系统上，SELinux可能会阻止mysqld进程的网络访问。可以临时设置为宽松模式测试：
setenforce 0。
最后，分享一个最易被忽略的“坑”：bind-address配置与防火墙规则的协同问题。假设MySQL配置了bind-address = 192.168.10.10，而防火墙只放行了192.168.10.55。此时，从192.168.10.55进行网络连通性检查是成功的，但权限校验依然会失败。为什么？因为MySQL服务端看到连接来自192.168.10.55，而你创建的用户却是'app'@'192.168.10.10'，两者根本不匹配。权限和网络，一个都不能错配。
