show variables 报错“command denied to user”是因为缺少 system_variables_admin 权限，而非 select 权限；mysql 8.0+ 中该权限专用于读写系统变量，需管理员执行 grant system_variables_admin on . to 'user'@'host'; 并 flush privileges 后验证。
为什么SHOW VARIABLES报错“command denied to user”
直接执行 SHOW VARIABLES 或 SELECT @@sql_mode 时出现 ERROR 1142 (42000): SELECT command denied to user，往往不是因为缺 SELECT 权限，而是用户缺少访问系统变量所需的底层权限。MySQL 8.0+ 默认收紧了对系统变量的读取控制，SHOW VARIABLES 实际依赖 SYSTEM_VARIABLES_ADMIN（或旧版本的 SUPER）权限，而非普通数据库表权限。
SYSTEM_VARIABLES_ADMIN 和 SUPER 权限的区别与兼容性
MySQL 8.0.16 起引入细粒度权限体系，SUPER 已被标记为 deprecated，推荐用 SYSTEM_VARIABLES_ADMIN 替代。但两者行为不完全等价：
-
SUPER是高危全能权限，覆盖变量、日志、复制、kill 线程等，不建议授予普通运维账号 -
SYSTEM_VARIABLES_ADMIN仅允许读写运行时变量（如sql_mode、max_connections），更安全 - MySQL 5.7 只支持
SUPER；MySQL 8.0+ 两者都可工作，但新账号应优先用SYSTEM_VARIABLES_ADMIN - 若用户同时有
SUPER，SYSTEM_VARIABLES_ADMIN会被自动隐式满足（反之不成立）
如何授予权限并验证是否生效
需用具有 GRANT OPTION 的管理员账号（如 root）执行：
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'your_user'@'localhost'; FLUSH PRIVILEGES;
验证方式不是查 SHOW GRANTS 是否含该词（有时显示为 SYSTEM_VARIABLES_ADMIN，有时在 SHOW GRANTS 中不显式列出），而是直接测试：
- 登录目标用户后执行
SHOW VARIABLES LIKE 'sql_mode';—— 成功即表示权限已就位 - 执行
SELECT @@innodb_buffer_pool_size;—— 若返回数值而非报错，说明变量读取通路已打开 - 注意：
FLUSH PRIVILEGES必须执行，否则权限缓存不会更新，即使GRANT语句返回成功
容易忽略的关键点
这个错误最常被误判为“表权限问题”，然后去反复 GRANT SELECT ON mysql.*，但实际无效——因为 mysql 库里的 global_variables 表是只读视图，且受独立权限控制。真正卡住的是权限模型层级：变量访问走的是 SYSTEM_VARIABLES_ADMIN 这条路径，和数据库/表级权限不在同一检查链上。如果你在 MySQL 8.0+ 上看到 SHOW VARIABLES 报错，第一反应不该是查用户有没有 SELECT，而应确认是否漏掉了这个专用权限。
