mysql表级权限可精确限制用户只访问某张表，需用grant select on database.table_name语法；必须指定数据库名，不能省略，且需先撤销更宽泛权限再单独授权目标表。
MySQL 表级权限是什么，能不能直接限制“只访问某张表”
可以，但不是靠 GRANT ... ON database.* 这种库级写法实现的。MySQL 的权限系统支持精确到表（table）甚至列（column）级别，关键在于 GRANT 语句中把对象写成 database.table_name，而不是 database.*。
注意：用户必须先有 USAGE 权限（即能连上），且不能跳过数据库名——即使当前 USE db1，也不代表对 db1 下所有表自动有权限。
如何给用户授予单张表的 SELECT 权限
用 GRANT 显式指定数据库名和表名，例如只允许用户 'appuser'@'localhost' 查询 myapp.users 表：
GRANT SELECT ON myapp.users TO 'appuser'@'localhost';
常见疏漏点：
- 没执行
FLUSH PRIVILEGES;—— 实际上只要GRANT成功，权限已写入mysql.tables_priv表，无需手动刷新（除非你直接改了系统表） - 误写成
GRANT SELECT ON users TO ...—— 缺少数据库名会导致语法错误或权限被赋予到默认库（如果当前有USE） - 用户已有更宽泛权限（如
SELECT ON myapp.*），新授予的细粒度权限不会覆盖旧权限，得先REVOKE
如何收回其他表的访问权，确保“仅此一张表”
MySQL 权限是累加的，所以必须显式撤回不需要的权限。比如用户之前有整个库的 SELECT，现在只想留 myapp.users：
REVOKE SELECT ON myapp.orders FROM 'appuser'@'localhost';<br>REVOKE SELECT ON myapp.logs FROM 'appuser'@'localhost';<br>-- 或批量回收库级权限（更常用）：<br>REVOKE SELECT ON myapp.* FROM 'appuser'@'localhost';<br>GRANT SELECT ON myapp.users TO 'appuser'@'localhost';
注意：
-
REVOKE不会报错于不存在的权限，可放心执行 - 撤销
myapp.*后再授予myapp.users，是最稳妥的“最小权限”做法 - 如果用户有
SELECT权限来自角色（MySQL 8.0+），需从角色中撤销，再单独授权
验证权限是否生效及常见失败原因
登录该用户后执行 SHOW GRANTS;，看输出是否只含目标表；再试查非授权表，应报错 ERROR 1142 (42000): SELECT command denied to user ... for table 'xxx'。
容易卡住的地方：
- 客户端缓存了旧连接，换新会话再测
- 用户 host 匹配不精确，比如授权的是
'appuser'@'192.168.1.%'，但实际连接用的是'appuser'@'192.168.1.100'—— 虽然匹配，但权限记录可能重复或冲突 - 使用了代理或中间件（如 ProxySQL），权限检查可能被绕过或延迟同步
表级权限本身开销极小，但大量细粒度授权会让 mysql.tables_priv 表变大，影响权限检查速度——不过几百张表以内基本无感。
