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';验证权限内容，比盲目重授更高效。
