GRANT EXECUTE失败主因是对象未创建或缺少Schema USAGE权限；需按数据库精确指定对象名及签名；推荐用角色批量管理权限；执行失败常因下游依赖权限缺失。
GRANT EXECUTE 时为什么提示“对象不存在”或“权限被拒绝”
常见原因是目标存储过程尚未创建，或当前用户没有对所属 Schema 的 USAGE 权限。PostgreSQL 和 SQL Server 行为略有不同，但核心逻辑一致：GRANT EXECUTE ON PROCEDURE（或 GRANT EXECUTE ON PROC）必须指向已存在且可解析的完整对象名。
- SQL Server 中需写成
GRANT EXECUTE ON [schema].[procedure_name] TO [user_or_role]，漏掉 schema（如dbo）会报错 - PostgreSQL 要求函数签名精确匹配，比如
GRANT EXECUTE ON FUNCTION my_proc(integer, text) TO alice，参数类型少一个字符（varcharvstext）就找不到对象 - MySQL 不支持直接对存储过程授 EXECUTE 权限，而是通过
GRANT EXECUTE ON PROCEDURE `db`.`proc_name` TO 'user'@'host'，且该用户必须已有SELECT权限在mysql.proc表上（5.7+ 默认关闭，需显式开启）
用角色（Role）批量管理存储过程权限比直接授给用户更安全吗
是的，而且这是生产环境的强制推荐做法。直接 GRANT EXECUTE 给用户会导致权限漂移——人员变动时容易遗漏回收，也难以审计谁有哪类操作权。
- 先创建专用角色，例如
role_report_executor，再GRANT EXECUTE ON PROCEDURE sales_summary TO role_report_executor - 把用户加入角色：SQL Server 用
ALTER ROLE role_report_executor ADD MEMBER alice；PostgreSQL 用GRANT role_report_executor TO alice - 禁止用户直接拥有 EXECUTE 权限，只允许通过角色继承——这样只需调整角色成员关系，无需反复修改 GRANT 语句
- 注意角色嵌套深度：SQL Server 支持多层角色继承，但超过 3 层可能影响执行计划缓存；PostgreSQL 角色不自动继承其他角色的权限，除非显式声明
INHERIT
如何限制存储过程只能被特定应用连接串调用，而不是任意用户
数据库原生不提供“按连接来源限制存储过程执行”的能力，所谓“精细化”在这里必须借助间接控制手段。
- 不要依赖用户名做判断——应用常复用固定数据库账号，无法区分终端用户
- 可在存储过程中检查
current_setting('app.user_id')（PostgreSQL）或SESSION_CONTEXT(N'user_id')（SQL Server），前提是应用在连接后主动设置该上下文值 - 更可靠的方式是分离账号：为每个应用分配独立登录名，并只给该登录名授予对应存储过程权限；配合防火墙或连接池策略（如 PgBouncer 的 user-based pooling）进一步隔离
- MySQL 可结合
DEFINER属性：定义存储过程时指定SQL SECURITY DEFINER，并让其以高权限账号（如definer_proc_runner）执行，而调用者只需有 EXECUTE 权限，不暴露底层表访问路径
GRANT 后存储过程仍执行失败，该查哪些隐藏权限点
EXECUTE 权限只是第一道门，真正执行时还可能因下游依赖缺失而中断，这类问题往往报错信息模糊，比如 “permission denied for table orders” 却没提是哪个存储过程里的语句触发的。
- 检查存储过程中所有引用的对象：表、视图、函数、序列，是否都对执行角色开放了对应权限（
SELECT、INSERT、USAGE等） - PostgreSQL 中，如果过程里用了
SECURITY DEFINER，则以定义者身份运行，但调用者仍需有对该过程的EXECUTE权限；若未设，则以调用者身份运行，所有下游对象权限都必须由调用者满足 - SQL Server 的模块签名（
ADD SIGNATURE）可绕过部分权限检查，但签名证书必须被显式信任，且UNSAFE ASSEMBLY权限不能随便开 - 临时表、表变量本身不涉及权限检查，但若过程里动态拼接 SQL 并
EXEC，则 EXEC 时的上下文权限才生效——这时候EXECUTE AS切换主体可能是唯一可控方式
GRANT EXECUTE 成功，不代表它真能跑通。 
