MySQL权限配置错误常致“Access denied”等问题，主因是用户@主机匹配不准、未执行FLUSH PRIVILEGES、权限层级混乱及过度授权；应严格遵循最小权限原则，用GRANT/REVOKE操作并确认CURRENT_USER()与SHOW GRANTS。
MySQL权限配置出错，最常导致“Access denied”、无法登录、SQL执行失败或权限过大等安全问题。核心在于对用户、主机、权限层级和刷新机制理解不到位。
用户@主机匹配不准确
MySQL权限判断是基于用户名 + 主机名组合的，不是只看用户名。常见错误包括：
- 创建用户时用
CREATE USER 'admin'@'localhost'，但应用连接时指定的是127.0.0.1——这两者在MySQL中被视为不同主机（localhost走socket，127.0.0.1走TCP），权限不生效 - 误以为
'user'@'%'能匹配所有地址，却忽略了'user'@'localhost'优先级更高，导致本地连接被更具体的规则覆盖 - 使用通配符主机如
'user'@'192.168.%.%'时，实际IP为192.168.10.5是匹配的，但写成'192.168.%'就不合法（缺少域名格式要求）
权限未生效：忘记 FLUSH PRIVILEGES
通过直接操作 mysql.user 等系统表修改权限后，必须执行 FLUSH PRIVILEGES; 才会重载权限缓存。但更推荐的做法是：
- 始终使用
GRANT/REVOKE语句授予权限（它们会自动刷新） - 避免直接 UPDATE mysql.user 表，除非清楚其字段含义（如
authentication_string替代旧版password字段） - 注意：MySQL 8.0+ 默认认证插件为
caching_sha2_password，旧客户端可能不兼容，需显式指定插件或调整用户认证方式
权限层级混乱：库/表级权限未配合USAGE
只给 SELECT 在某个库，却不赋予该用户全局 USAGE 权限（即登录能力），会导致用户能连上但看不到任何数据库（SHOW DATABASES 返回空）。正确做法是：
- 先确保用户有基本连接权：
GRANT USAGE ON *.* TO 'u1'@'%' IDENTIFIED BY 'pwd'; - 再授予具体对象权限：
GRANT SELECT ON mydb.* TO 'u1'@'%'; - 若需看到库名，还要额外授权：
GRANT SHOW DATABASES ON *.* TO 'u1'@'%';（MySQL 8.0.12+ 默认隐藏未授权库）
过度授权与最小权限原则违背
生产环境常见高危操作：
- 用
GRANT ALL PRIVILEGES ON *.*创建“管理员”，却未限制主机范围（如写成@'%'而非@'10.0.0.%'） - 给应用账号赋予
DROP、CREATE USER、GRANT OPTION等高危权限，一旦SQL注入就可能提权 - 长期使用 root 连接业务程序，未建立专用低权限账号（例如只读账号应仅含
SELECT+SHOW VIEW）
权限问题本质是匹配逻辑 + 刷新机制 + 层级控制三者的叠加结果。查问题时优先用 SELECT CURRENT_USER(), USER(); 确认实际匹配的账号，再查 SHOW GRANTS FOR 'u'@'h'; 验证权限内容，比盲目重授更高效。
