MySQL通过CREATE USER 'user'@'host'限制登录IP，支持'192.168.1.%'等通配符模拟网段，不支持CIDR；须配合GRANT授权和FLUSH PRIVILEGES生效，且需删除'%''冗余账号防冲突。
限制用户从哪些 IP 登录，不是 DBeaver 的功能，而是 MySQL（或其他数据库）服务端的权限控制逻辑。DBeaver 只是客户端，它不参与、也无法干预“谁被允许连接进来”这件事。
MySQL 8.x 中用 CREATE USER 指定登录来源 IP
你必须在数据库服务端执行 SQL 来绑定用户与 IP。MySQL 通过用户名后缀 @'host' 精确控制来源：
-
'user1'@'192.168.1.100'：只允许该 IP 连接 -
'user1'@'192.168.1.%'：允许整个 C 段（如192.168.1.5、192.168.1.254） -
'user1'@'localhost'：仅本机 socket 连接（注意：这和127.0.0.1是两个不同 host） -
'user1'@'%'：允许任意 IP —— 生产环境应避免
示例（MySQL 8.x）：
CREATE USER 'app_user'@'10.20.30.40' IDENTIFIED BY 'StrongPass!2026'; GRANT SELECT, INSERT ON mydb.* TO 'app_user'@'10.20.30.40'; FLUSH PRIVILEGES;
执行后，该用户只能从 10.20.30.40 这台机器用 DBeaver（或任何客户端）连接，其他 IP 会直接报 Access denied for user。
为什么 GRANT ... IDENTIFIED BY 在 MySQL 8.x 会报 ERROR 1064
MySQL 8.0+ 废弃了在 GRANT 语句中直接设置密码的语法。如果你写：
GRANT ALL ON *.* TO 'u'@'%' IDENTIFIED BY 'p';
就会触发 ERROR 1064 (42000) —— 因为 IDENTIFIED BY 不再是 GRANT 的合法子句。
正确做法是分两步：
- 先
CREATE USER 'u'@'%' IDENTIFIED BY 'p'; - 再
GRANT ... TO 'u'@'%';
注意：如果用户已存在，CREATE USER 会报错，此时应改用 ALTER USER 'u'@'%' IDENTIFIED BY 'p';。
DBeaver 里填的 IP 对权限没影响，但会影响实际连接路径
你在 DBeaver 连接配置里填的 Host 字段（比如 10.20.30.40 或 db.example.com），只是告诉 DBeaver “往哪儿发 TCP 包”。它不会修改数据库权限规则，也不会自动帮你加白名单。
但这个值间接决定了 MySQL 用哪个 user@host 规则来匹配：
- 如果你填
127.0.0.1，MySQL 会尝试匹配'u'@'127.0.0.1'，而不是'u'@'localhost' - 如果你填
localhost，MySQL 优先走 Unix socket，匹配'u'@'localhost' - 如果你填域名，MySQL 会做 DNS 解析，最终匹配解析出的 IP 对应的
user@ip条目
所以，测试时别只换密码，要同步核对 DBeaver 填的 host 和数据库里 CREATE USER 用的 host 是否一致。
真正容易被忽略的是：MySQL 的 host 匹配是精确字符串比对，'user'@'192.168.1.0/24' 这种 CIDR 写法不支持；IP 段只能靠 % 或 _ 通配，且 % 不能出现在 IP 中间（比如 '192.168.%' 是非法的）。
