DBeaver 不参与权限授予，需在SQL编辑器中执行数据库原生GRANT语句；MySQL须用高权限账号指定routine名授权；SQL Server受所有权链限制；PostgreSQL/Oracle需按对象类型与schema精确授权。
直接给用户授予 EXEC 权限这件事，DBeaver 本身不参与权限授予逻辑——它只是个客户端，真正执行授权的是数据库服务端。你得在 DBeaver 的 SQL 编辑器里运行对应数据库的 GRANT 语句，而不是点几下鼠标就完成授权。
MySQL 中用 DBeaver 授予 EXEC 权限要先确认函数/存储过程存在且可查
MySQL 实际上不区分“存储过程权限”和“函数权限”，统一由系统表 mysql.proc 管理，但普通用户默认看不到这个表。如果你在 DBeaver 里执行 SHOW PROCEDURE STATUS 或查询 mysql.proc 报错 Access denied，说明当前登录用户连元数据都读不了，更别说授予权限了。
- 必须用高权限账号（如
root）连接，才能执行GRANT EXECUTE ON PROCEDURE db_name.sp_name TO 'user'@'host' - MySQL 8.0+ 中，
EXECUTE权限是 schema 级或 routine 级的，不能只给 database 级；写法必须带具体过程名，例如：GRANT EXECUTE ON PROCEDURE testdb.CPP_DEL_ALL_Tb_Demo TO 'TonyZhang'@'%' - 如果想批量授权所有 routine，可用
GRANT EXECUTE ON FUNCTION testdb.* TO ...或GRANT EXECUTE ON PROCEDURE testdb.* TO ...，但注意这不等价于GRANT EXECUTE ON testdb.*（后者无效） - 执行完记得
FLUSH PRIVILEGES（仅当使用INSERT INTO mysql.*直接改表时才强制需要；用标准GRANT语句通常不用）
SQL Server 中通过 DBeaver 执行 GRANT 需注意所有权链限制
你在 DBeaver 里执行 GRANT EXEC ON dbo.CPP_DEL_ALL_Tb_Demo TO TonyZhang 是能成功的，但后续调用是否真能跑通，取决于存储过程内部用了什么语句。比如过程里用了 TRUNCATE TABLE，哪怕已授 EXEC，也会报错——因为所有权链只覆盖 SELECT/INSERT/UPDATE/DELETE，不覆盖 TRUNCATE、DROP、动态 SQL 等。
- 若过程内含
TRUNCATE，用户还需单独被授予该表的ALTER权限 - 若过程内拼接了动态 SQL（如
EXEC('DELETE FROM ...')），所有权链完全失效，用户必须对目标表有显式DELETE权限 -
EXECUTE AS子句可以绕过部分限制，但需 DBA 显式配置，且 DBeaver 不提供图形化设置入口
PostgreSQL 和 Oracle 在 DBeaver 里授 EXEC 权限本质不同
PostgreSQL 没有“执行存储过程权限”这个概念，只有 EXECUTE 权限作用于函数（FUNCTION）或过程（PROCEDURE，PG 11+）。Oracle 同理，权限对象是 PROCEDURE 或 FUNCTION，不是“存储过程整体”。DBeaver 只负责把你的 GRANT EXECUTE ON FUNCTION my_func TO user1 发给服务端。
- PostgreSQL：必须指定 schema，如
GRANT EXECUTE ON FUNCTION public.my_proc(int) TO alice；重载函数签名不同时，权限不自动继承 - Oracle：语法为
GRANT EXECUTE ON schema.pkg_name TO user或GRANT EXECUTE ON schema.proc_name TO user；注意大小写敏感，若对象名建时加了双引号，授权时也得带引号 - 两者都不支持类似 MySQL 的
GRANT EXECUTE ON PROCEDURE db.*这种通配写法
真正容易被忽略的是：权限生效不等于调用成功。DBA 给了 EXEC，不代表过程里所有操作都能过权限检查——尤其是涉及跨 schema 表访问、临时表、序列、UDF 调用时，每个环节都可能卡在权限上。别急着怀疑 DBeaver，先在服务端用 SHOW GRANTS FOR ... 或 SELECT * FROM role_tab_privs 确认权限确实落到了目标对象上。
