MySQL用户登录失败主因是权限配置错误：'user'@'localhost'与'127.0.0.1'被视为不同主机；ERROR 1045常因认证插件不兼容、空密码或skip-grant-tables残留；OS权限仅影响启动或socket访问。
MySQL 用户无法登录：检查 mysql.user 表中的主机匹配
操作系统权限问题常被误判，实际多是 MySQL 自身权限配置错误。最典型的是用户创建时指定了 'user'@'localhost'，但客户端用 127.0.0.1 连接——这两个在 MySQL 中被视为不同主机，localhost 走 Unix socket，127.0.0.1 走 TCP，权限不互通。
- 执行
SELECT User, Host FROM mysql.user;确认当前用户绑定的Host值 - 若需本地任意方式连接，建议创建
'user'@'%'或显式添加'user'@'127.0.0.1' - 修改后必须执行
FLUSH PRIVILEGES;，否则变更不生效 - 注意：
'user'@'%'允许任意 IP 连接，生产环境应限制为具体内网段，如'user'@'192.168.1.%'
ERROR 1045 (28000)：密码验证失败的三个常见原因
这个错误看似是密码错，但常和权限表状态、认证插件或空密码策略有关。
- MySQL 8.0+ 默认使用
caching_sha2_password插件，旧客户端（如某些 Python MySQLdb）不兼容，可改用mysql_native_password：ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 用户存在但
authentication_string字段为空（尤其从低版本升级后），需重置密码：SET PASSWORD FOR 'user'@'%' = 'pwd'; - MySQL 配置了
skip-grant-tables后忘记关闭，会导致所有用户免密登录，但其他权限逻辑异常；检查my.cnf是否残留该配置
操作系统文件权限干扰 MySQL 启动或 socket 访问
当 MySQL 完全无法启动，或客户端报 Can't connect to local MySQL server through socket，才真正涉及操作系统权限。
- 确认
/var/lib/mysql/（或datadir指向路径）属主是mysql:mysql，且权限为750或755；禁止设为777 - Unix socket 文件（如
/var/run/mysqld/mysqld.sock）需对运行 MySQL 的用户（通常是mysql）可读写，且所在目录也要有执行权限（x）才能进入 - SELinux 启用时，可能拦截 socket 创建，临时验证可用
setenforce 0；长期解决需调整上下文：semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
GRANT 语句没生效？注意作用域和反向 DNS
执行 GRANT SELECT ON db.* TO 'user'@'192.168.1.100'; 后仍连不上，可能是 DNS 反查失败导致主机名匹配失败。
- MySQL 默认开启
skip_name_resolve = OFF，会尝试反向解析客户端 IP 对应的域名，若 DNS 不稳定或无 PTR 记录，可能导致匹配到'user'@'%'失败 - 稳妥做法是：在 MySQL 配置中设置
skip_name_resolve = ON，并确保所有GRANT语句都用 IP 或'%'，不用主机名 -
GRANT不会覆盖已有权限，只追加；要彻底重置，先DROP USER 'user'@'host';再重建
MySQL 权限体系里，Host 字段的匹配优先级、认证插件的客户端兼容性、以及操作系统层 socket 文件的访问控制，这三处最容易被当成“权限问题”却查错方向。调试时先分清是连接阶段失败（看 error log 中的 mysqld 启动日志），还是认证后操作失败（看 SHOW GRANTS 输出是否符合预期）。
