MySQL中localhost与127.0.0.1是两个独立账号，分别对应'user'@'localhost'和'user'@'127.0.0.1'两条权限记录，认证插件、密码、权限互不影响；连接方式不同（Unix socket vs TCP/IP），需分别授权且保持认证方式一致。
localhost 和 127.0.0.1 在 MySQL 中是两个独立账号
MySQL 不会把 'user'@'localhost' 和 'user'@'127.0.0.1' 当成同一个账号——它们在 mysql.user 表里是两条不同记录，权限、认证插件、密码哈希都互不影响。你给前者授权了，后者照样连不上；改了前者的密码，后者的登录不受任何影响。
典型表现是：mysql -u u -p（默认走 localhost）能进，但 mysql -u u -p -h 127.0.0.1 报 ERROR 1045 (28000) 或 Access denied；或者 PHP 用 127.0.0.1 连失败，换 localhost 就通。
- 用
SELECT User, Host FROM mysql.user WHERE User = 'u';查清到底有哪些匹配项 - Navicat / DBeaver 等工具默认走 TCP，即使填
localhost也常被解析为127.0.0.1，除非显式勾选 “Use socket” - IPv6 下
::1同样需要单独授权，%不覆盖它
如何一次性让 localhost 和 127.0.0.1 都可用
最稳妥的做法不是“统一”，而是分别授权，且保持认证方式一致。尤其 MySQL 8+ 默认用 caching_sha2_password，而老客户端或 PHP 扩展可能只支持 mysql_native_password。
执行以下语句（注意替换 u 和密码）：
CREATE USER 'u'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pwd'; CREATE USER 'u'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'pwd'; GRANT ALL ON *.* TO 'u'@'localhost'; GRANT ALL ON *.* TO 'u'@'127.0.0.1'; FLUSH PRIVILEGES;
- 不要依赖
'u'@'%'替代，它不解决本地连接问题，还放大攻击面 -
IDENTIFIED WITH显式指定插件，避免因服务端默认值变更导致兼容性断裂 - 如果已存在账号，优先用
ALTER USER修改插件和密码，而非DROP + CREATE
为什么 FLUSH PRIVILEGES 后还是不生效
FLUSH PRIVILEGES 只重载内存中的权限表，它本身不修复账号缺失或认证不匹配。真正卡住的往往是连接时没匹配到正确账号，或者旧连接还在用缓存的权限上下文。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 已有连接的权限在握手完成那一刻就固定了，
FLUSH PRIVILEGES对它完全无效 - 执行完授权后，必须
QUIT;再重新登录，或换新连接验证（比如新开终端跑mysql -u u -p -h 127.0.0.1） - PHP 中改了配置要重启 PHP-FPM 或 Apache，否则 mysqli/pdo 连接池里的旧连接仍沿用旧状态
- 某些情况下，
GRANT语句本身已自动刷新权限（MySQL 5.7+），FLUSH PRIVILEGES是冗余操作
SELinux 或防火墙拦截 127.0.0.1 的 TCP 连接
当 localhost（socket）能连、127.0.0.1（TCP）死活不通，且确认账号和权限无误时，大概率是系统层拦截。CentOS/RHEL 系环境下，SELinux 常静默拒绝 Apache/PHP 进程访问 3306 端口。
快速验证：
sestatus -v | grep http ausearch -m avc -ts recent | grep mysqld
- 临时关闭：运行
/usr/sbin/setenforce 0，再试连接 - 永久关闭：编辑
/etc/selinux/config，设SELINUX=disabled，然后重启 - 更安全做法是保留 SELinux，用
setsebool -P httpd_can_network_connect_db 1开放数据库连接权限 - 别忘了检查
iptables或nftables是否拦了 loopback 流量
真正麻烦的从来不是授权语句写得对不对，而是你根本不知道当前连接走的是哪条链路、匹配的是哪条用户记录、受哪层策略约束。查 mysql.user、看客户端实际 host、关 SELinux 试一次——这三步做完，90% 的“权限冲突”就自然解开了。
