应使用 WITH EXECUTE AS OWNER 或专用执行账户（如 proc_executor）并显式拒绝用户表级权限，才能确保存储过程权限隔离；需清除执行计划缓存以使新权限生效。
直接给用户只授 EXECUTE 权限是不够的——只要存储过程里写了 UPDATE，且用户本身有对应表的 UPDATE 权限，那语句照样执行成功。真正起作用的是让过程在受限上下文中运行。
用 EXECUTE AS OWNER 切换执行身份
这是最常用也最稳妥的方式：存储过程以创建者（通常是 dbo 或专用高权限账户）身份运行，调用者只需 EXECUTE 权限，不继承其原始表权限。
- 创建过程时必须显式加上
WITH EXECUTE AS OWNER，不能省略 - 避免用
EXECUTE AS SELF，否则维护者变更后权限会意外漂移 - 如果过程只读，
OWNER账户也应仅被授予SELECT权限，而非db_owner - 过程内若访问系统视图（如
sys.tables），需额外给OWNER账户VIEW DEFINITION权限
先收掉用户的表级权限，再单独授 EXECUTE
很多人跳过这步，结果用户仍能绕过过程直连表操作。必须主动撤销其对底层表的直接访问权。
- 用
DENY SELECT, INSERT, UPDATE, DELETE ON [schema].[table] TO [user]显式拒绝，比REVOKE更强（DENY优先级高于GRANT） - 不要依赖“没给权限就默认不能访问”——
public角色可能已隐式继承了某些权限 - 检查是否误加了
db_datareader或db_owner角色，这些会覆盖细粒度限制 - 验证方式：用该用户登录后执行
SELECT TOP 1 * FROM [table]，应报错“拒绝了对对象的 SELECT 权限”
用专用执行账户替代 OWNER 更可控
直接用 dbo 当 OWNER 风险偏高，推荐建一个最小权限账户专供过程调用。
- 新建登录和用户，如
proc_executor，禁止交互式登录（不配密码策略、不映射到其他数据库） - 只授予它对过程所涉表的必要字段权限，例如
GRANT SELECT(id, name) ON users TO proc_executor - 过程定义中写
WITH EXECUTE AS 'proc_executor'，而非OWNER - 该账户不参与任何其他逻辑，权限变更只需改它，不影响其他过程或用户
最容易被忽略的一点：权限生效不是即时的。SQL Server 缓存执行计划时可能沿用旧权限上下文，修改后建议清空相关缓存（DBCC FREEPROCCACHE）或重启连接验证。另外，所有 DENY 操作必须在目标数据库上下文中执行，切库遗漏会导致限制失效。
