Access Denied错误主要拒绝认证失败的用户，而非权限不足；它卡在用户存在性、密码、host匹配或账号状态等认证前端环节，90%情况未进入权限检查阶段。
Access Denied 错误到底在拒绝谁？
MySQL 的 Access denied for user 'xxx'@'yyy' 不是笼统的“没权限”，而是卡在认证链最前端：用户不存在、密码错、host 不匹配，或账号被禁用。90% 的 case 根本没走到权限检查那步——先查账号是否存在、是否能连上，再谈授权。
- 用
SELECT User, Host FROM mysql.user;确认账号是否真实存在，注意Host字段必须和你连接时用的客户端 IP 或域名完全一致（'user'@'192.168.1.%'不等于'user'@'192.168.1.100'） - 检查连接命令里写的 host：本地用
localhost连，和用127.0.0.1连，MySQL 视为两个不同 host，前者走 socket，后者走 TCP，账号也得分别授权 - 确认密码是否正确：5.7+ 默认用
caching_sha2_password插件，老客户端可能不兼容，临时改用mysql_native_password可快速验证是不是插件问题
GRANT 之后为什么还是 Access Denied？
执行了 GRANT 却无效，大概率因为没刷权限表或权限范围写错了。MySQL 不自动重载权限，且 GRANT 的 ON 子句必须精确匹配你访问的对象层级。
- 执行完
GRANT后，必须跟一句FLUSH PRIVILEGES;（仅当直接改了mysql.user表才强制需要；用GRANT命令一般不需要，但加了不报错，排查时建议加上） -
GRANT SELECT ON db.* TO 'u'@'h';—— 这个权限只对db库下的表生效，访问db.tbl可以，但SELECT * FROM db（库级操作）或SHOW DATABASES都不行 - 如果要用通配符库名（如
`test_%`），必须用反引号包裹，且该语法只在 8.0+ 支持；5.7 不支持模糊库名授权
ERROR 1045 和 ERROR 1044 的区别在哪？
ERROR 1045 (28000): Access denied for user 是认证失败，ERROR 1044 (42000): Access denied for user ... to database 才是真正的权限不足。别被“Access denied”字面意思带偏。
-
ERROR 1045：检查mysql.user表，看authentication_string是否为空、account_locked是否为Y、password_expired是否为Y -
ERROR 1044：说明用户已通过认证，但当前语句越权。比如用普通账号执行CREATE DATABASE，或没USAGE权限却想连指定库（mysql -u u -p -D forbidden_db） - 用
SHOW GRANTS FOR 'u'@'h';查实际生效权限，注意输出里可能有多个GRANT记录，MySQL 取并集，但DENY（8.0+）会覆盖
MySQL 8.0 权限系统变化带来的坑
8.0 把权限拆得更细，引入角色（role）、动态权限、以及默认禁用部分旧行为，老脚本或迁移后容易静默失效。
-
CREATE USER默认不再自动赋予USAGE权限，新用户建完连SELECT 1都会报ERROR 1044，必须显式GRANT USAGE ON *.* TO ... - 密码策略变严格：
validate_password插件默认启用，设简单密码会失败，错误提示仍是Access denied，但实际卡在SET PASSWORD阶段 - 系统库权限收紧：
performance_schema、information_schema不再默认可读，要查慢日志或会话状态，得单独授权，否则SELECT * FROM performance_schema.session_status直接报ERROR 1044
权限问题最麻烦的不是不会配，而是错误信息太笼统，掩盖了真实断点。多看 mysql.user 表字段、紧盯 SHOW GRANTS 输出、分清 1045 和 1044——这三件事做扎实了，一半的“Access Denied”当场就能定位到行。
