MySQL Workbench中“用户和权限”入口位于Management > Users and Privileges，仅当以root等具备SELECT权限访问mysql.user表且拥有GRANT OPTION的管理员账号连接时才显示；host为'%'与'localhost'是两条独立用户记录，认证方式与网络路径不同，赋权后需执行FLUSH PRIVILEGES并验证CURRENT_USER()确保匹配预期账户。
MySQL Workbench 没有叫“安全中心”的独立模块——你看到的其实是 Management > Users and Privileges 这个权限管理入口，它被部分用户误称为“安全中心”。
为什么在 Workbench 里找不到 Users and Privileges？
这不是功能缺失，而是权限控制逻辑在前端做了隐藏：
- 必须用
root或具备SELECT权限访问mysql.user表、且拥有GRANT OPTION的账号连接，菜单才出现 - 如果连接时指定了
Default Schema（比如填了test），而该库不存在，整个权限模块可能加载失败 - 新版 Workbench（8.0.30+）把入口移到
Management > Users and Privileges，但普通用户登录后该菜单项直接不渲染 - 云数据库（如阿里云 RDS）常禁用 SSL，若连接配置里没勾选
Enable SSL，即使 root 登录也可能触发认证降级，导致权限界面空白
host 填 % 还是 localhost？关键区别在哪
MySQL 把 'user'@'localhost' 和 'user'@'%' 当作两条完全独立的用户记录，权限不共享、认证方式不同：
-
localhost走 Unix socket，绕过 TCP/IP 栈；%必须走网络连接，受防火墙、DNS 解析影响 - 本地命令行执行
mysql -u user -p默认尝试localhost，哪怕你只建了user@'%'，也会报Access denied - 云环境严禁
host = '%'，必须填具体 IP（如192.168.1.100）或 CIDR 段（如10.0.0.0/24） - Workbench 创建用户时，“Limit to Hosts Matching”字段别留空——默认就是
%，想锁死本地就手动改成localhost
赋权后点 Apply 为什么还不生效？
Workbench 的 Apply 按钮会自动生成并执行 GRANT 语句，但以下情况仍需人工干预：
- 某些旧版 MySQL 或 MariaDB 不自动触发权限重载，需手动执行
FLUSH PRIVILEGES; - 权限只对已存在的数据库生效：
GRANT SELECT ON nonexistent_db.*不报错，但后续创建同名库也不会继承权限 - 应用连接时指定的
database名必须和授权时的库名严格一致；给了db1.*却连db2，就会因无库级权限被拒 - 检查实际认证身份：执行
SELECT USER(), CURRENT_USER();，前者是客户端声明的身份，后者才是 MySQL 实际匹配的用户记录（决定用哪条权限）
最容易被忽略的是 CURRENT_USER() 和 USER() 的差异——很多连不上问题，根源在于你以为连的是 user@'%'，其实 MySQL 匹配到了 user@'127.0.0.1' 或 user@'::1' 这类 IPv6 地址记录，而它们的权限是空的。
