不建议用触发器做租户隔离，因其易绕过、难审计、性能差且并发批量下易失效；应由应用层强制注入tenant_id并配合rls或视图封装实现安全隔离。

触发器无法可靠实现多租户数据自动隔离

直接结论：不建议用触发器做租户隔离。它容易绕过、难审计、性能差，且在并发或批量操作时极易失效。真正安全的隔离必须由应用层或数据库访问层（如中间件、ORM）强制注入 tenant_id 条件，并配合行级安全策略（RLS）或视图封装。

为什么 BEFORE INSERT/UPDATE 触发器常被误用

常见错误是写一个触发器自动填充 tenant_id 字段，比如：

CREATE TRIGGER set_tenant_id BEFORE INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION set_current_tenant();

问题在于：

• 应用仍可显式插入 tenant_id = 999（其他租户ID），触发器不校验合法性
• UPDATE 触发器无法阻止跨租户修改（例如 UPDATE orders SET amount=100 WHERE id=123 不带 tenant_id 条件）
• 批量导入（COPY、pg_restore）或 DBA 直连操作完全绕过触发器
• PostgreSQL 中触发器不参与行级安全（RLS）决策，不能替代 USING (tenant_id = current_setting('app.tenant_id'))

真正起作用的替代方案：RLS + 应用层绑定

以 PostgreSQL 为例，正确路径是：

• 为每张业务表启用 RLS：ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
• 创建策略强制匹配当前会话租户：CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.tenant_id', true)::bigint);
• 应用每次连接后立即执行：SET app.tenant_id = '123';（需确保连接池支持 session-level 设置）
• 禁用超级用户对租户表的直查权限：REVOKE SELECT ON orders FROM public;

这样即使 SQL 漏写 WHERE tenant_id = ?，数据库也会静默过滤掉其他租户数据。

如果非要用触发器，至少加校验逻辑

仅在无法启用 RLS 的旧版数据库（如 MySQL 5.7）中，可退而求其次用触发器做「租户字段存在性+一致性」检查：

DELIMITER $$
CREATE TRIGGER check_tenant_before_update BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
  IF NEW.tenant_id != OLD.tenant_id THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'tenant_id cannot be changed';
  END IF;
  IF NEW.tenant_id IS NULL OR NEW.tenant_id != @current_tenant THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid or missing tenant_id';
  END IF;
END$$
DELIMITER ;

但注意：@current_tenant 必须由应用在每个语句前显式设置（SET @current_tenant = 123;），且无法防御 prepared statement 绕过、连接复用污染等场景。

租户隔离的关键从来不是“能不能加逻辑”，而是“有没有办法让非法访问根本构造不出合法 SQL”。触发器做不到这点。