最可靠方法是用 SELECT 'GRANT EXECUTE ON OBJECT::' + QUOTENAME(schema_name(schema_id)) + '.' + QUOTENAME(name) + ' TO [AppUser];' FROM sys.procedures WHERE is_ms_shipped = 0 动态生成语句，限定 sys.procedures 避免误授，用 QUOTENAME() 防特殊字符，禁用 EXEC(@sql) 执行权限语句。
直接用 GRANT EXECUTE 批量生成语句最可靠
手动给上百个存储过程逐条授权不现实，也容易漏。核心思路是：从 sys.procedures 动态查出所有目标存储过程，拼成一批 GRANT EXECUTE 语句，再一次性执行。这不是“黑魔法”，而是 SQL Server 原生支持的元数据驱动方式。
常见错误是直接对 sys.objects 或 sys.all_objects 查询 —— 它们包含视图、函数等杂项，容易误授或报错。必须限定为 sys.procedures，它只返回真正的存储过程（不含系统过程）。
-
OBJECT_ID()和OBJECT_NAME()不适合批量场景：它们一次只能处理一个对象，无法在 SELECT 中批量展开权限语句 - 不要用
INFORMATION_SCHEMA.ROUTINES：它不区分用户/系统过程，且缺少架构信息，拼出来的语句可能缺[schema].前缀导致执行失败 - 若需排除特定存储过程（如以
usp_开头的调试用过程），可在 WHERE 条件里加AND name NOT LIKE 'usp_%_debug'
GRANT EXECUTE ON OBJECT:: 是唯一推荐语法
SQL Server 2005+ 起，GRANT EXECUTE ON [schema].[proc_name] TO [user] 这种旧写法虽仍可用，但已不推荐。必须用带双冒号的 OBJECT:: 限定符，否则在跨架构或含特殊字符的名称时会出错（比如 [My.Schema].[Proc.Name] 会被解析失败）。
示例生成脚本：
SELECT 'GRANT EXECUTE ON OBJECT::' +
QUOTENAME(schema_name(schema_id)) + '.' + QUOTENAME(name) +
' TO [AppUser];'
FROM sys.procedures
WHERE is_ms_shipped = 0
AND schema_id IN (SCHEMA_ID('dbo'), SCHEMA_ID('hr'));
关键点：
-
is_ms_shipped = 0自动过滤掉系统存储过程（如sp_help），避免GRANT报错 -
QUOTENAME()必须包裹 schema 名和 proc 名：防止名称含空格、短横线或保留字（如[order]）导致语法错误 - 输出结果是纯文本语句，复制进新查询窗口执行即可；不要试图用
EXEC(@sql)动态执行——权限语句不能嵌套在动态 SQL 中生效
按架构批量授权比按单个过程更高效
如果用户需要执行某个架构下**所有当前及未来新增**的存储过程，直接授予权限到架构层级，一劳永逸。例如：
GRANT EXECUTE ON SCHEMA::[hr] TO [AppUser];
这比遍历每个过程快得多，且后续新建的存储过程自动继承权限。但要注意：
- 该权限仅作用于该架构下的存储过程，不影响同库其他架构（如
dbo或sales） - 不会授予对表、视图或函数的权限——哪怕它们也在同一架构下。函数需单独用
GRANT EXECUTE ON FUNCTION:: - 若架构中混有不应执行的过程（如维护用的
usp_rebuild_indexes），就不能用此法，必须回到过程级粒度控制
验证是否真生效，别只看语句没报错
执行完批量授权后，很多人以为完事了，结果用户还是报 The EXECUTE permission was denied on the object。根本原因常是：权限被显式 DENY 覆盖，或用户不在目标数据库上下文中。
快速验证方法：
- 用目标用户身份连库后执行：
SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE');看是否有EXECUTE行 - 查具体过程权限：
SELECT permission_name, state_desc FROM sys.database_permissions p JOIN sys.procedures o ON p.major_id = o.object_id WHERE o.name = 'usp_GetData' AND p.grantee_principal_id = USER_ID('AppUser'); - 注意
state_desc是GRANT还是DENY：DENY优先级永远高于GRANT，必须先REVOKE或DROP掉DENY记录
真正麻烦的不是生成授权语句，而是权限叠加和覆盖规则——一个 DENY 就能让整批 GRANT 失效，这点最容易被忽略。
