在DBeaver中执行REVOKE必须使用具备GRANT OPTION或更高权限的账号（如root、sa），普通业务账号无权操作；语法需严格匹配数据库规范：SQL Server须用REVOKE SELECT ON OBJECT::[schema].[table] TO [user]，MySQL须用REVOKE SELECT ON db.table FROM 'user'@'host'，且权限变更仅对新连接生效。
在DBeaver里执行REVOKE必须用对应数据库用户身份
你不能用普通业务账号（比如 test）去回收自己或别人的表权限——REVOKE 是 DDL 操作，需要具备 GRANT OPTION 或更高权限（如 DBA、sysadmin）。DBeaver 只是客户端，权限控制完全由后端数据库（如 SQL Server、MySQL）执行。常见错误是：用 test 用户连上去，写 REVOKE SELECT ON sysdba.t1 FROM test;，结果报错 Cannot revoke permissions you don't own 或类似提示。
实操建议：
- 确认当前连接的数据库用户是否拥有目标表的
CONTROL权限（SQL Server）或GRANT OPTION（MySQL） - 如果没权限，得换一个高权限账号重连，比如
sa（SQL Server）或root（MySQL） - DBeaver 左上角连接名右键 → Disconnect，再右键 → Edit Connection → 修改登录凭证
SQL Server中收回单表权限的正确语法是REVOKE + ON OBJECT::
SQL Server 不像 MySQL 那样直接写 REVOKE SELECT ON table_name FROM user。它要求显式指定对象类型，否则会报错 Incorrect syntax near 'ON'。必须用 OBJECT:: 前缀声明这是表对象。
示例（以 sa 身份执行）：
REVOKE SELECT ON OBJECT::[sysdba].[t1] TO [test];
注意点：
- 库名和表名要用方括号
[ ]包裹，尤其当名字含点号、空格或大小写敏感时 -
TO后面是被授权人，不是FROM（容易和 MySQL 记混） - 如果之前是用
WITH GRANT OPTION授予的，要加CASCADE才能一并收回下游转授的权限：REVOKE SELECT ON OBJECT::[sysdba].[t1] TO [test] CASCADE;
MySQL下用DBeaver回收权限要注意认证插件兼容性
如果你用的是 MySQL 8.0+ 默认的 caching_sha2_password 插件，而 DBeaver 版本较旧（比如低于 23.3），可能连不上高权限账号，导致根本没法执行 REVOKE。这不是权限问题，是连接层失败。
验证方式：在 DBeaver 连接配置的 Driver Properties 里检查 allowPublicKeyRetrieval 是否为 true，useSSL 是否设为 false（开发环境可接受）。
回收语句本身很简单：
REVOKE SELECT ON `sysdba`.`t1` FROM 'test'@'%';
但必须注意：
- 用户名和 host 要跟
GRANT时完全一致，'test'@'localhost'和'test'@'%'是两个不同账号 - 执行完需运行
FLUSH PRIVILEGES;（仅部分 MySQL 版本需要，DBeaver 中可另开 SQL 编辑器执行） - 权限变更不会立即影响已存在的连接，新连接才生效
回收后查不到数据？先确认对象所有权和默认架构
即使 REVOKE 成功，用户仍可能查到数据——比如 SQL Server 中，如果 test 用户是 t2 表的所有者，它默认仍有 SELECT 权限（除非显式 DENY）。或者，用户连的是 test 数据库，默认架构是 dbo，但表建在 sysdba 架构下，没写三段式名就查不到，误以为权限失效。
排查步骤：
- SQL Server：查
sys.database_permissions确认该用户对目标对象是否有残留GRANT或DENY - MySQL：用
SHOW GRANTS FOR 'test'@'%';看当前实际授予的权限 - 执行查询时务必写全限定名，如
SELECT * FROM sysdba.t1;，避免因默认 schema 导致行为偏差
最容易被忽略的是：权限回收不等于“禁止访问”，而是“撤销显式赋予的访问权”。对象所有者、public 角色、数据库级权限都可能构成隐式通路，得一层层核对。
