SQL Server中存储过程权限必须显式授予EXECUTE且不可继承，回收须用REVOKE而非DENY；授权语法为GRANT EXECUTE ON OBJECT::[schema].[proc] TO [user/role]，需先USE目标库并确保用户已映射。
SQL Server 中存储过程的权限必须显式授予 EXECUTE，不能靠表权限自动继承；回收时也必须用 REVOKE，DENY 会阻断后续 GRANT。
GRANT EXECUTE ON 存储过程的具体写法
授权执行单个存储过程，必须指定 ON OBJECT :: 语法，否则会报错或作用于错误对象。数据库上下文（USE）和架构名（如 dbo、HumanResources）缺一不可。
-
USE必须在GRANT之前执行，否则权限会被授予到master或当前默认库 - 完整语法是
GRANT EXECUTE ON OBJECT ::[schema].[procedure_name] TO [user_or_role]，漏掉OBJECT ::可能被解析为架构级权限 - 用户必须已存在，且在目标数据库中已映射为数据库用户（
CREATE USER ... FOR LOGIN） - 示例：
USE Company_report20221019; GRANT EXECUTE ON OBJECT ::dbo.usp_GetReportData TO xxbbbb;
批量授权：对整个架构下的所有存储过程授予权限
当项目中有大量存储过程，且需统一开放给某角色时，直接对架构授予权限比逐个操作更可靠、易维护。但要注意：这仅影响当前已存在及未来新建的存储过程（只要它们属于该架构），不涉及函数、视图或表。
- 语法是
GRANT EXECUTE ON SCHEMA ::[schema_name] TO [user_or_role] - 例如：
GRANT EXECUTE ON SCHEMA ::dbo TO app_reader;—— 这比循环授权几十个usp_*更安全 - 若后续新增了存储过程但未刷新权限缓存，执行时仍可能报
Permission denied，建议执行后用SELECT * FROM sys.database_permissions WHERE permission_name = 'EXECUTE'核查 - 注意：
DENY EXECUTE ON SCHEMA优先级高于GRANT，一旦存在 DENY 就会彻底封禁，哪怕再 GRANT 也无效
REVOKE vs DENY：回收权限时的关键区别
误用 DENY 是最常见的权限回收陷阱。它不是“取消授权”，而是主动设置拒绝标记，且无法被同级 GRANT 覆盖——哪怕你之后再次 GRANT EXECUTE，该用户依然执行失败。
- 正确回收方式是
REVOKE EXECUTE ON OBJECT ::[schema].[proc] FROM [user] -
DENY应仅用于明确禁止某用户访问特定对象的场景（例如审计要求），日常运维请避免使用 - 回收架构级权限同样用
REVOKE EXECUTE ON SCHEMA ::dbo FROM [user] - 如果已误用
DENY，必须先REVOKE EXECUTE ON OBJECT ::... FROM [user]，再GRANT才能恢复
验证权限是否生效的实用方法
不要依赖“执行没报错”就认为权限到位——SQL Server 的权限检查发生在语句编译阶段，某些缓存或延迟可能导致行为不一致。
- 查用户是否有 EXECUTE 权限：
SELECT * FROM sys.database_permissions p JOIN sys.objects o ON p.major_id = o.object_id WHERE o.name = 'usp_GetEmployeeDetails' AND p.grantee_principal_id = USER_ID('xxbbbb'); - 检查结果中
state_desc应为GRANT，而非DENY或空 - 用目标用户身份登录后执行
EXECUTE AS USER = 'xxbbbb'; EXEC dbo.usp_GetEmployeeDetails @EmployeeID=1; REVERT;实测最可靠 - 注意：若存储过程中引用了其他表或视图，而用户没有对应 SELECT 权限，即使 EXECUTE 成功，运行时仍会报错——EXECUTE 权限 ≠ 过程内所有操作都可执行
真正麻烦的从来不是写对一条 GRANT，而是搞清权限链里哪一层被 DENY 卡住、哪个架构没切对、或者用户根本不在当前数据库里映射。动手前先 SELECT USER_NAME() 和 SELECT DB_NAME() 确认上下文，比反复试错快得多。
