必须显式授予每张允许查询的表并回收全局权限，因MySQL权限模型为“显式授权、默认拒绝”，无表级白名单快捷语法；列级SELECT需在GRANT中明确字段名，且不阻止JOIN间接获取；元数据访问需单独撤销INFORMATION_SCHEMA权限。
MySQL 用户只能执行 SELECT 且仅限特定表怎么办
直接结论：不能靠 SELECT 权限本身做“表级白名单”，必须显式授予每张允许查询的表，同时回收全局权限。MySQL 的权限模型是“显式授权、默认拒绝”，没有“除某几张表外全部禁止”的快捷语法。
常见错误是只给 db_name.* 的 SELECT，结果用户能查整个库；或者误以为 REVOKE SELECT ON *.* 能一键清空所有查询权——其实它不作用于已显式授予的库/表级权限。
- 先用
SHOW GRANTS FOR 'user'@'host';确认当前实际生效的权限（注意：USAGE不代表无权限，只是连接权） - 逐条撤销不需要的权限，例如：
REVOKE SELECT ON `other_db`.* FROM 'user'@'host'; - 对目标表精确授权：
GRANT SELECT ON `mydb`.`allowed_table1` TO 'user'@'host';和GRANT SELECT ON `mydb`.`allowed_table2` TO 'user'@'host'; - 执行
FLUSH PRIVILEGES;生效（仅在直接改mysql系统表后必需；用GRANT/REVOKE通常自动刷新）
想限制用户只能查某些字段（列级权限）怎么设
MySQL 支持列级 SELECT，但仅限单表，且必须在 GRANT 时明确列出字段名，不能用通配符。它不阻止用户通过 JOIN 或子查询间接获取其他字段，所以本质是“弱防护”，适合内部轻量约束。
例如只允许查 users 表的 id 和 name：
GRANT SELECT(id, name) ON `mydb`.`users` TO 'report_user'@'%';
注意：
- 如果用户已有
SELECT ON mydb.users全表权限，列级授权不会覆盖它；必须先REVOKE SELECT ON mydb.users -
INSERT/UPDATE/DELETE不支持列级控制，只有SELECT和REFERENCES可以 - 视图（
VIEW）比列级权限更可控：建一个只含所需字段的视图，再授SELECT给视图
为什么用户还能执行 SHOW CREATE TABLE 或 INFORMATION_SCHEMA 查询
因为这些不是“表数据查询”，而是元数据访问，默认不受 SELECT 权限控制。用户只要拥有任意一张表的 SELECT 权限，就能查 INFORMATION_SCHEMA.TABLES（受限于其能访问的库），甚至可能推断出其他表名。
真正限制元数据可见性需关闭 information_schema 的全局访问或启用 show_compatibility_56=OFF（MySQL 5.7+ 默认关），但最有效的是：
- 用
REVOKE SELECT ON `INFORMATION_SCHEMA`.* FROM 'user'@'host';（MySQL 8.0.12+ 支持） - 降权到最小必要：避免授予
PROCESS、SHOW DATABASES、SHOW VIEW等辅助权限 - 若用 MySQL 8.0+，可配合角色（
ROLE）封装权限集，便于复用和审计
权限生效延迟或不生效的典型原因
不是所有权限变更都立即可用。最容易被忽略的是权限作用域与客户端连接时使用的认证上下文不一致。
- 检查
host是否匹配：用户定义为'user'@'192.168.1.%'，但连接用的是localhost，则匹配'user'@'localhost'这条记录（而它可能没授权） - 权限缓存未刷新：虽然
GRANT多数情况自动刷新，但若之前用INSERT INTO mysql.tables_priv手动改过，必须FLUSH PRIVILEGES; - 代理用户（proxy user）机制开启时，实际生效的是被代理用户的权限，而非登录用户的
- MySQL 8.0+ 的密码认证插件（如
caching_sha2_password）不影响权限，但若连接失败，会误判为权限问题
复杂点在于权限是分层叠加的：列级 + 表级 + 库级 + 全局，优先级从高到低，且 DENY（MySQL 8.0.16+ 的角色拒绝机制）会覆盖 GRANT。别指望一条命令搞定，得一层层核对 SHOW GRANTS 输出。
