SQL Server存储过程中安全获取租户ID须依赖应用层调用sp_set_session_context显式设置tenant_id，再用SESSION_CONTEXT(N'tenant_id')读取并校验，禁用CONTEXT_INFO及系统用户函数；校验需用IS NOT DISTINCT FROM处理NULL，失败时用THROW中断执行。
SQL Server 存储过程中怎么安全拿到调用方的租户/用户上下文
存储过程本身没有“当前业务用户”概念，CURRENT_USER、SUSER_NAME() 返回的是数据库登录身份，不是应用层的租户ID或操作员ID。必须由应用在执行前显式注入上下文。
最可靠方式是使用 SESSION_CONTEXT()：应用每次获取连接后立即执行 EXEC sp_set_session_context @key = N'tenant_id', @value = N'tenant_abc'。存储过程中读取时务必加 @fallback_null = 0 参数（即不设默认值），否则未设置时返回 NULL，容易被绕过校验：
DECLARE @tenant_id NVARCHAR(128) = SESSION_CONTEXT(N'tenant_id');
别用 CONTEXT_INFO：只能存128字节二进制，多键冲突、类型转换易出错；也别查 sys.dm_exec_sessions 反推——需要高权限，且并发下可能读到其他会话数据。
如何在存储过程中动态校验权限并拦截非法访问
权限校验不能只靠 SELECT 权限开关，得结合业务规则做行级过滤或显式拒绝。关键点是：校验逻辑必须在数据访问前执行，且对 NULL 值敏感。
- 用
IS NOT DISTINCT FROM替代=，避免@tenant_id = t.tenant_id在任一为 NULL 时恒为 FALSE（从而漏判） - 若租户ID字段是
UNIQUEIDENTIFIER类型，而SESSION_CONTEXT()返回NVARCHAR，必须显式转换：CAST(SESSION_CONTEXT(N'tenant_id') AS UNIQUEIDENTIFIER) - 校验失败时用
THROW 50000, 'Access denied: tenant mismatch', 1中断执行，不要只返回空结果集 - 避免在 WHERE 条件里直接拼租户ID——万一
SESSION_CONTEXT为空，整条语句就变成无条件查询
为什么不能在存储过程中直接查用户表做权限计算
看似“查 user_roles 表 + join permission_rules 表”很直观，但实际踩坑极多：
— 权限表本身也要受租户隔离，查权限前就得先用租户ID过滤权限表，形成循环依赖
— 多级角色继承、动态策略（如“部门主管可看本部门+下属部门订单”）会让 SQL 变得复杂难维护，且难以命中索引
— 每次调用都实时计算权限，性能开销大，尤其在高频小查询场景（如订单详情页加载）
更稳妥的做法是：权限预计算 + 缓存。应用层在登录或切换租户时，调用专用存储过程 sp_calculate_user_permissions，把结果写入临时表或内存优化表（如 #user_perms），后续业务存储过程直接 JOIN 这个临时结构。这样既解耦，又可控。
Oracle/MySQL 存储过程里怎么适配这套思路
Oracle 没有原生 SESSION_CONTEXT，得用 DBMS_SESSION.SET_IDENTIFIER 或绑定变量传参；MySQL 则依赖用户自定义变量（@tenant_id）或 sys.schema_table_statistics_with_buffer 等伪视图——但都不如 SQL Server 的 SESSION_CONTEXT 安全可靠。
跨数据库统一做法是：强制所有存储过程第一个参数为 @tenant_id 或 p_tenant_id，由应用层严格传入，存储过程开头就做非空和格式校验。这样虽增加调用方负担，但彻底规避上下文丢失风险。
真正容易被忽略的是连接池复用问题：ADO.NET 或 JDBC 连接池会复用物理连接，如果上一个请求设置了 tenant_id，下一个请求没重置，就会导致租户数据越界。必须确保每次业务请求开始时都调用一次 sp_set_session_context，不能只在连接初始化时设一次。
