用户show databases仅见系统库，主因是权限未匹配目标主机、bind-address限制远程访问或认证插件不兼容，需依次核查host精确匹配、监听地址配置及caching_sha2_password插件适配。
用户存在但 SHOW DATABASES 看不到库
执行了 GRANT 并 FLUSH PRIVILEGES，登录后运行 SHOW DATABASES 却只看到 information_schema 和 performance_schema，说明权限没生效或不匹配。核心问题不是“有没有权限”，而是“权限对谁、对哪个库生效”。
-
GRANT SELECT ON mydb.* TO 'user'@'%'只让该用户看到mydb，看不到其他库；如果想看到所有库，得给SELECT权限到*.*（或至少mysql库的SELECT，否则连mysql都不可见） - 用户登录时用的是
mysql -h 192.168.1.100 -u user -p，那匹配的是'user'@'192.168.1.100'，不是'user'@'%'——Host字段必须完全一致，%不会匹配 IP 字面量（除非 DNS 解析失败且skip_name_resolve=ON） - MySQL 8.0+ 默认启用
sql_mode=STRICT_TRANS_TABLES，若用户权限中含CREATE TEMPORARY TABLES但未显式授予，某些客户端（如旧版 DBeaver）在初始化连接时会静默失败，表现为能登录但查不到库
bind-address 仍为 127.0.0.1 导致远程授权形同虚设
即使 'user'@'%' 权限写得再全，只要 MySQL 只监听本地回环地址，外部 TCP 包根本进不来。这是远程连不上最常被跳过的环节。
- Linux 下检查
/etc/mysql/mysql.conf.d/mysqld.cnf或/etc/my.cnf中[mysqld]段的bind-address—— 若为127.0.0.1，必须注释掉或改为0.0.0.0 - 改完不重启服务，配置不会加载；验证是否生效：运行
ss -tln | grep :3306，输出里应有*:3306或0.0.0.0:3306，而非仅127.0.0.1:3306 - 云服务器上还要确认安全组放行 3306 入方向，不能只开系统防火墙（如
ufw）
MySQL 8.0+ 的 caching_sha2_password 认证插件不兼容旧客户端
用户能连上，但一执行 SHOW DATABASES 就断开，或直接报 Access denied，很可能是认证插件不匹配。这不是权限问题，是握手阶段就失败了。
- 运行
SELECT User, Host, plugin FROM mysql.user WHERE User = 'user';，看plugin列是不是caching_sha2_password - PHP 7.4 以下、Navicat 12 以下、部分 JDBC 驱动默认不支持该插件；临时解决：执行
ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 不建议全局改默认插件（影响所有新用户），只针对出问题的用户单独调整
账户被锁、密码过期或 account_locked 为 Y
权限和网络都通，但登录后立刻被踢，或者 SHOW GRANTS 返回空，大概率是账户状态异常。这个点容易被忽略，因为错误提示不明确。
- 查状态：运行
SELECT User, Host, account_locked, password_expired FROM mysql.user WHERE User = 'user'; - 若
account_locked = 'Y'，执行ALTER USER 'user'@'%' ACCOUNT UNLOCK; - 若
password_expired = 'Y'，需重置密码：ALTER USER 'user'@'%' IDENTIFIED BY 'newpwd';（注意：MySQL 8.0+ 不再支持SET PASSWORD）
真正卡住人的地方，往往不在 SQL 权限本身，而在 Host 匹配逻辑、bind-address 监听范围、认证插件兼容性这三层叠加。一次连不上，先别急着反复 GRANT，按顺序查这三处，90% 的问题当场定位。
