登录成功但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 user\G

• 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，容易掩盖真实瓶颈。