安全获取当前租户ID须动态绑定而非硬编码，主流方案是应用层透传并配合会话变量（如PostgreSQL的current_setting、MySQL的@tenant_id），触发器中需校验非空且禁止篡改，分库分表或读写分离下该方案易失效。
触发器里怎么安全获取当前租户ID
直接在触发器里硬编码 tenant_id 值等于放弃隔离——必须动态绑定。主流做法是依赖数据库会话变量或应用层透传的上下文。PostgreSQL 支持 current_setting('app.tenant_id')，MySQL 8.0+ 可用 @tenant_id 用户变量，但前提是应用每次请求前已执行 SET @tenant_id = 'xxx'。漏设、未重置、连接复用时残留旧值，都会导致数据错写。
- 应用必须在事务开始前、执行业务 SQL 前，显式设置租户变量（如
SET @tenant_id = 't_123'） - 触发器内需做非空校验，避免插入 NULL 导致约束失败：
IF NEW.tenant_id IS NULL THEN SET NEW.tenant_id = @tenant_id; END IF; - 连接池场景下，务必配置「连接初始化语句」（如 HikariCP 的
connection-init-sql），清空或重设租户变量
INSERT 触发器自动填充 tenant_id 的写法差异
不同数据库对 NEW 行的修改支持程度不同。MySQL 允许在 BEFORE INSERT 中直接赋值 NEW.tenant_id；PostgreSQL 的 BEFORE INSERT 触发器函数必须返回 NEW，且字段赋值语法是 NEW.tenant_id := current_setting('app.tenant_id');。SQL Server 不支持在触发器中修改插入行（只能用 INSTEAD OF），得换思路。
- MySQL：用
BEFORE INSERT，直接写SET NEW.tenant_id = IFNULL(@tenant_id, 'invalid'); - PostgreSQL：函数返回
NEW，且需提前用SET LOCAL app.tenant_id = 't_123'设置会话级配置 - Oracle：用
BEFORE EACH ROW，赋值用:NEW.tenant_id := SYS_CONTEXT('APP_CTX', 'tenant_id');，依赖应用先调用DBMS_SESSION.SET_CONTEXT
UPDATE 触发器为什么必须校验 tenant_id 不可篡改
用户可能绕过应用层，直连数据库执行 UPDATE orders SET tenant_id = 't_456' WHERE id = 123。如果触发器只管 INSERT，这条语句就能跨租户污染数据。必须在 BEFORE UPDATE 里拦截非法修改——但注意：不能简单地「覆盖」NEW.tenant_id，否则业务真要改其他字段（如 status）时，tenant_id 会被意外重置。
- 正确做法是对比
OLD.tenant_id和NEW.tenant_id，若不一致则报错：SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'tenant_id cannot be changed'; - MySQL 8.0+ 可用
IF NEW.tenant_id != OLD.tenant_id THEN ... END IF;，但别用SET NEW.tenant_id = OLD.tenant_id静默修正——这会让错误操作看起来成功 - 触发器里禁止调用外部函数（如查表判断租户权限），否则更新性能雪崩
触发器方案在分库分表或读写分离下的失效点
一旦上 ShardingSphere 或 MyCat 这类中间件，SQL 被路由前，触发器根本没机会运行。更麻烦的是，从库通常关闭触发器（MySQL slave-skip-errors=1786 就跳过触发器错误），导致主库写入正常、从库数据缺失 tenant_id，同步后全表数据变成脏租户。
- 分库分表环境下，触发器自动注入彻底不可用，必须把
tenant_id作为必填参数由应用拼进所有 SQL - 读写分离时，确保从库也启用触发器（MySQL 需设
replicate_do_table并关掉skip-slave-start），但代价是复制延迟升高 - 云数据库（如阿里云 RDS、AWS RDS）常默认禁用自定义触发器，或限制
SUPER权限——先查文档，别等上线才发现不支持
触发器看着省事，但租户ID一旦漏传、错传或被绕过，隔离就形同虚设。真正关键的不是“怎么写触发器”，而是“怎么确保每条语句都带着正确的租户上下文进来”。
