MySQL连接被拒绝时，先查host
和user
是否匹配
MySQL权限是按
user@host组合精确匹配的，不是只看用户名。比如
'app'@'localhost'和
'app'@'127.0.0.1'在MySQL眼里是两个完全不同的账号，因为
localhost走socket连接，
127.0.0.1走TCP，底层host解析结果不同。 执行
SELECT User, Host FROM mysql.user;确认实际存在的账号组合 用
mysql -u app -h 127.0.0.1 -p测试时，必须存在
'app'@'127.0.0.1'或
'app'@'%'
'app'@'%'能匹配所有IP，但不匹配
localhost（这是MySQL的特殊规则） 若需统一，可删掉
'app'@'localhost'，只留
'app'@'127.0.0.1'和
'app'@'%'
GRANT后仍无权限？别忘了FLUSH PRIVILEGES
不是万能的
执行
GRANT语句本身就会实时更新权限缓存，不需要手动
FLUSH PRIVILEGES；反而是直接改
mysql.user表后才需要它。误用
FLUSH不仅多余，还可能掩盖真正问题——比如你改的是错的行，或者没提交事务（InnoDB引擎下直接UPDATE权限表需显式
COMMIT）。 正确做法：用
GRANT SELECT ON db1.* TO 'reader'@'%';，然后用
SHOW GRANTS FOR 'reader'@'%';验证 如果用
UPDATE mysql.user SET Select_priv='Y' WHERE User='reader';，必须跟
FLUSH PRIVILEGES;且确保已
COMMIT
SHOW GRANTS看到的权限，才是MySQL当前实际生效的，比查表更可靠
ERROR 1045 (28000): Access denied怎么快速定位
这个错误只说明认证失败，但没说清是密码错、用户不存在，还是host不匹配。不能只盯着密码改。
先用mysql -u root -p -h 127.0.0.1连本地，确认服务正常、root密码可用 再查
SELECT host,user,authentication_string,account_locked FROM mysql.user WHERE user='xxx';，看
account_locked是否为
Y检查
authentication_string是否为空（老版本MySQL可能用
Password字段，新版本统一为
authentication_string） 如果用的是sha256_password插件，客户端必须支持（如MySQL 8.0+默认），旧版客户端连不上会直接报1045，而非提示插件不兼容
最小权限原则落地时，USAGE
权限容易被忽略
新建账号后什么权限都不给，它其实自动拥有
USAGE权限——这意味着能连上，但执行任何操作都会报错。这看似“安全”，实则埋雷：应用日志里全是权限错误，运维第一反应却是查密码或网络，浪费大量时间。 建号后立刻
GRANT明确权限，不要依赖默认
USAGE对只读账号，用
GRANT SELECT ON db1.table1 TO 'ro'@'%';，而不是
GRANT SELECT ON *.*删除权限用
REVOKE，不用
DROP USER——后者会连账号一起删，而
REVOKE可精准回收，适合权限迭代场景
权限配置里最麻烦的从来不是语法，而是host匹配逻辑和权限继承关系。哪怕
GRANT写对了，只要
user@host组合和客户端实际发起连接的地址不一致，就必然失败。调试时优先用
SHOW GRANTS和
SELECT ... FROM mysql.user交叉验证，别信记忆里的“应该可以”。
