sql server存储过程实现分级权限控制必须显式使用execute as切换执行上下文；默认execute as caller模式下调用者权限直接生效，无隔离效果；推荐用execute as owner或指定专用账户（如proc_executor），确保过程内所有操作均受固定权限约束，且所有权链要求访问对象属同一owner。
SQL Server 存储过程能实现分级权限控制，但必须显式用 EXECUTE AS 切换执行上下文；不写这句，默认就是调用者权限，等于没隔离。
EXECUTE AS OWNER 是最常用且安全的切换方式
它让存储过程始终以创建者（通常是 dbo 或专用高权限账户）身份运行，调用者只需有 EXECUTE 权限，无需底层表的任何 SELECT/INSERT 权限。
- 创建时必须显式声明：
CREATE PROCEDURE dbo.GetActiveOrders WITH EXECUTE AS OWNER AS ... - 所有权链生效前提：过程里访问的所有对象（表、视图、其他过程）都得属于同一个 owner（比如全是
dbo），否则权限检查会中断 - 别用
EXECUTE AS SELF：它把创建时的 login/user 名字硬编码进过程定义，换 DBA 维护后容易因 owner 变更导致执行失败 - 如果 owner 是
dbo，确保dbo账户本身不被普通用户直接登录或滥用
EXECUTE AS 'username' 适合需要固定低权限上下文的场景
比如你有个专用执行账户 proc_executor，只被授予 UPDATE 某几个字段的权限，也不允许交互式登录——这时就该用它，而不是直接用 OWNER。
- 声明方式：
CREATE PROCEDURE dbo.UpdateOrderStatus WITH EXECUTE AS 'proc_executor' AS ... - 该账户必须已存在，且数据库中已有对应
USER（不能只是 server-level login） - 过程内部所有语句都受
proc_executor的权限约束，哪怕它没被授予SELECT，那过程里也不能查表——这是可控的限制，不是 bug - 注意：如果过程里还调用了另一个过程，而那个过程没设
EXECUTE AS，那调用链会回落到 caller 权限，可能意外突破边界
不设 EXECUTE AS 就等于裸奔，尤其对跨 schema 或动态 SQL
默认 EXECUTE AS CALLER 下，用户只要能执行过程，就能顺带执行过程里所有语句——包括 SELECT * FROM sys.tables 这种元数据扫描，或者拼接出来的任意表名。
- 常见错误现象：
The SELECT permission was denied on the object 'sys.tables'—— 表明你没关掉 caller 模式，又没给用户授元数据权限 - 动态 SQL（
EXEC(@sql)）在CALLER模式下完全继承调用者权限，极易被注入利用；换成OWNER或指定用户后，动态 SQL 的执行范围就被严格框定 - 跨 schema 访问（如
sales.Customers）会立即中断所有权链，除非两个 schema 的 owner 完全一致，否则必须显式授权或改用EXECUTE AS - MySQL 完全不支持这个机制，它的过程权限 = 调用者权限 + 表级权限，别指望靠过程做隔离
权限回收和测试必须用真实用户上下文验证
用 EXECUTE AS USER = 'test_user' 测试，比用 sa 或 dbo 登录跑一遍更真实——因为只有这时你才能暴露“所有权链断裂”或“EXECUTE AS 账户缺权限”的问题。
- 测试前先确认：
REVOKE SELECT ON sales.orders FROM PUBLIC，再撤掉所有非必要角色，避免权限从public继承 - 过程里如果用了
INSERT INTO audit_log，而audit_log表不在同一 schema 或 owner 不同，就得单独给EXECUTE AS账户授INSERT权限 - 别忘了禁用
guest用户：它会让没显式授权的用户通过guest身份偷偷连进来，绕过你的过程封装 - 最易忽略的一点：
EXECUTE AS只作用于当前过程，不传递给它调用的函数（UDF）或触发器——这些对象得各自配置权限或上下文
