安全获取当前租户ID须动态绑定而非硬编码，主流方案是应用层透传并配合会话变量（如PostgreSQL的current_setting、MySQL的@tenant_id），触发器中需校验非空且禁止篡改，分库分表或读写分离下该方案易失效。
触发器里怎么安全获取当前租户ID
触发器本身没有上下文概念，CURRENT_USER 或 SESSION_USER 通常返回数据库账号，不是业务租户。必须依赖外部传入——最可靠的方式是让应用层在会话中显式设置变量，再在触发器里读取。
PostgreSQL 示例（MySQL 类似但语法不同）：
SET app.tenant_id = 'tenant_abc';
然后触发器内用 current_setting('app.tenant_id', true) 获取。注意第二个参数设为 true，否则租户ID未设置时会报错而非返回 NULL。
- 别用
pg_backend_pid()+ 临时表模拟会话变量——并发下极易冲突 - 避免在触发器里查配置表反推租户——增加 I/O、破坏原子性、可能死锁
- 如果用连接池（如 PgBouncer），确保使用 transaction 模式而非 session 模式，否则
SET不生效
INSERT 触发器必须声明为 BEFORE ROW
只有 BEFORE ROW 触发器能修改即将插入的行数据。用 AFTER 就只能补更新，既多一次写入又无法防止空租户ID被写入。
PostgreSQL 示例：
CREATE OR REPLACE FUNCTION set_tenant_id()
RETURNS TRIGGER AS $$
BEGIN
NEW.tenant_id := current_setting('app.tenant_id', true);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER ensure_tenant_id
BEFORE INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION set_tenant_id();
-
NEW是可写的，OLD在 INSERT 中不存在 - 若表已有
tenant_id字段且 NOT NULL，触发器里没赋值就会报错；若允许 NULL，得加判空逻辑防止覆盖 - 触发器函数返回
NULL会直接丢弃该行插入——可用于强制校验，但要慎用
租户ID字段类型和索引必须提前对齐
触发器填进去的值，类型必须和列定义完全一致。常见翻车点：应用传的是字符串 '123'，而字段是 INT，触发器不做转换就直接赋值，导致类型不匹配错误。
MySQL 示例（需显式转换）：
SET NEW.tenant_id = CAST(@tenant_id AS UNSIGNED);
- 所有含
tenant_id的表，该字段名、类型、是否允许 NULL 必须统一，否则触发器无法复用 - 每个租户表都得建
(tenant_id, id)或(tenant_id, created_at)复合索引，否则按租户查数据会全表扫 - 别忘了给
tenant_id加CHECK约束（如CHECK (tenant_id ~ '^[a-z0-9_]{5,32}$')），防异常值污染
测试时最容易漏掉的并发与回滚场景
单条 INSERT 测试通过不代表线上安全。两个关键盲区：
- 事务中多条 INSERT 共享同一个会话变量——但如果中间有
SAVEPOINT+ 回滚，变量值不会自动还原，后续语句可能拿到旧租户ID - 批量 INSERT（如
INSERT ... SELECT）触发器仍逐行执行，但current_setting在整条语句生命周期内只读一次，没问题；可一旦混用 CTE 或子查询，某些 PG 版本会出现变量读取时机异常
真正保险的做法：在应用层封装 DAO 方法，每次执行 SQL 前做两件事——先 SET 租户变量，再用 BEGIN; ... COMMIT/ROLLBACK 包裹，不依赖触发器兜底。
触发器只是最后防线，不是租户隔离的唯一手段。
