登录成功但 SHOW TABLES 报错是因缺少库表级权限，需用 SELECT DATABASE()确认当前库，SHOW GRANTS FOR CURRENT_USER 检查权限，再通过 GRANT 授权并 FLUSH PRIVILEGES 生效。
mysql登录成功但执行 SHOW TABLES 报错 Access denied 怎么办
登录成功只说明认证通过，不代表有库或表级操作权限。常见现象是输入 mysql -u user -p 能进命令行，但一执行 SHOW TABLES 就报ERROR 1142 (42000): SELECT command denied to user 'user'@'localhost' for table 'users'，本质是用户没被授予对应数据库的SELECT（或其他）权限。
- 先确认当前用的是哪个库：
SELECT DATABASE();，返回NULL说明还没选库 - 再查当前用户权限：
SHOW GRANTS FOR CURRENT_USER;，重点看是否含类似GRANT SELECT ON `mydb`.* TO 'user'@'localhost'的语句 - 如果只有
USAGE权限（即仅允许连接），那所有 DML/DDL 操作都会被拒绝 - 注意权限 作用域 ：即使对
mydb有权限，若执行USE otherdb再SHOW TABLES，仍会因缺少otherdb权限而失败
给 MySQL 用户添加库级权限的正确写法
权限必须显式授予，且需刷新才能生效。直接 GRANT ALL PRIVILEGES ON mydb.* TO 'user'@'localhost'; 不加 FLUSH PRIVILEGES; 可能无效，尤其在较新版本中权限缓存更严格。
- 授予权限前确保目标库存在：
CREATE DATABASE IF NOT EXISTS mydb; - 授权语句要带引号包裹数据库名（含特殊字符或大小写敏感时必需）：
GRANT SELECT, INSERT, UPDATE ON `mydb`.* TO 'user'@'localhost'; - 主机名必须匹配：若用户是
'user'@'192.168.1.%'，用localhost登录则权限不生效 - 执行完务必运行：
FLUSH PRIVILEGES;，否则权限变更不会加载到内存
为什么 root@localhost 也无法操作某些表
MySQL 8.0+ 默认启用 sql_require_primary_key 或启用了严格模式，但更常见的原因是表属于系统库（如 mysql、performance_schema），普通root 用户默认也没有写权限——这是安全限制，不是 bug。
-
mysql.user表只能由具有SYSTEM_USER特权的账户修改，普通root可能只有CREATE USER等基础管理权 - 检查是否误连到只读实例：执行
SELECT @@read_only;，返回1表示该实例禁止写入 - 确认存储引擎是否支持：比如
MEMORY表重启后丢失，FEDERATED表权限需远程服务端配合 - 触发器或视图定义中引用了无权限的表，也会导致
SELECT失败，错误提示未必指向真实源头
排查权限问题的最小验证步骤
别急着改权限，先用最简路径确认问题范围。以下命令按顺序执行，每步都应有明确预期结果：
SELECT USER(), CURRENT_USER(); USE mysql; SELECT COUNT(*) FROM user LIMIT 1; SHOW CREATE TABLE userG-
USER()显示客户端声明的身份，CURRENT_USER()才是 MySQL 实际匹配的账号，二者不一致常因 host 通配符或匿名用户干扰 - 如果
USE mysql失败，说明连库权限都没有；如果SELECT失败，说明缺表级SELECT权限；如果SHOW CREATE TABLE报错，则可能是SHOW VIEW权限缺失 - 所有权限检查必须在目标库上下文中进行，切勿在
information_schema里查别的库权限——它不实时反映权限变更
权限粒度比想象中细，一个 SELECT 操作背后可能涉及SELECT、SHOW VIEW、EXECUTE（对函数）甚至LOCK TABLES（在某些隔离级别下）。跳过验证直接授ALL PRIVILEGES，容易掩盖真实瓶颈。
