SQL Server 2016 多租户隔离不推荐仅用触发器，须配合 SESSION_CONTEXT、IS NOT DISTINCT FROM 和行级安全（RLS）；CURRENT_USER 和 CONTEXT_INFO 不可靠，必须用 sp_set_session_context 设置 tenant_id 并在触发器中显式读取校验。
SQL Server 2016 中用触发器做多租户隔离，不是推荐方案，而是兜底手段——它能拦住漏掉 tenant_id 的写入，但拦不住漏加 WHERE tenant_id 的读取；且极易因连接池复用、NULL 比较失效、字段类型不匹配导致越权。真要上，必须配合 SESSION_CONTEXT + IS NOT DISTINCT FROM + 行级安全（RLS）三者共用，否则等于裸奔。
为什么不能用 CURRENT_USER 或 CONTEXT_INFO 拿租户ID
触发器里调用 CURRENT_USER、SESSION_USER 或 SUSER_NAME() 返回的是登录账户名（比如 app_user），不是业务租户ID；CONTEXT_INFO 只能存 128 字节二进制，多个键会互相覆盖，且读取时需 CONVERT 转换，容易出错。唯一可靠路径是应用层每次获取连接后执行：
EXEC sp_set_session_context @key = N'tenant_id', @value = N'tenant_abc'
然后在触发器中用 SESSION_CONTEXT(N'tenant_id') 读取——注意必须显式声明变量接收，不能直接在 WHERE 条件里嵌套调用，否则可能被优化跳过。
AFTER INSERT/UPDATE 触发器怎么校验并拦截非法 tenant_id
核心就两件事：检查新行的 tenant_id 是否与会话值一致，且不允许为空或错配。别用 = 或 !=，它们在任一操作数为 NULL 时返回 UNKNOWN，条件不成立。
- 必须用
IS NOT DISTINCT FROM：它把 NULL 当作相等值处理，语义更安全 - 字段类型要严格对齐：如果列是
UNIQUEIDENTIFIER，而SESSION_CONTEXT()返回NVARCHAR，得显式CAST(SESSION_CONTEXT(N'tenant_id') AS UNIQUEIDENTIFIER) - 表上不能有
DEFAULT值（如DEFAULT 'public'），否则会覆盖触发器逻辑 - 示例片段：
CREATE TRIGGER tr_orders_tenant_check ON orders AFTER INSERT, UPDATE AS
BEGIN
DECLARE @tenant_id NVARCHAR(128) = SESSION_CONTEXT(N'tenant_id');
IF EXISTS (
SELECT 1 FROM inserted i
WHERE i.tenant_id IS NOT DISTINCT FROM @tenant_id
) = 0
BEGIN
RAISERROR('tenant_id mismatch or missing', 16, 1);
ROLLBACK;
END
END
DELETE 触发器为什么比 INSERT/UPDATE 更关键
因为 DELETE 不带租户条件的 WHERE 很容易越权删光其他租户数据——比如 DELETE FROM orders WHERE id = 123，没加 AND tenant_id = ... 就全表扫。
- 必须在
BEFORE DELETE或AFTER DELETE中检查deleted.tenant_id -
deleted表中每行都有tenant_id值（它是已存在的行），所以不用判空，但必须用IS NOT DISTINCT FROM防止 NULL 导致绕过 - 不能只查
inserted（DELETE 没有inserted），也不能试图重写 WHERE（触发器做不到） - 一旦发现
deleted.tenant_id IS NOT DISTINCT FROM @tenant_id不成立，立刻RAISERROR并回滚
最容易被忽略的三个点
第一，ADO.NET 连接池默认复用物理连接，应用必须确保每次 HTTP 请求开始时都重设 SESSION_CONTEXT，不能只在首次打开连接时设一次；第二，RLS 策略必须启用，否则触发器只管写不管读，SELECT 仍可越权；第三，所有租户表的 tenant_id 字段必须统一命名、统一类型、不允许为 NULL——少一个约束，就少一层保障。
