安全获取当前租户id的唯一可靠路径是应用层显式传入并在触发器中读取：postgresql用current_setting('app.tenant_id', true)，mysql用cast(@tenant_id as unsigned)；连接池须用transaction模式；before row触发器中必须赋值new.tenant_id并返回new。
触发器里怎么安全获取当前租户ID
触发器本身没有业务上下文，CURRENT_USER 返回的是数据库账号，不是租户。必须由应用层显式传入，并在触发器中读取——这是唯一可靠路径。
- PostgreSQL 推荐用
current_setting('app.tenant_id', true)，第二个参数设为true才能避免未设置时直接报错，返回NULL便于后续判空 - MySQL 对应的是会话变量
@tenant_id，但注意类型：如果字段是INT，得用CAST(@tenant_id AS UNSIGNED)显式转换，否则插入失败 - 连接池（如 PgBouncer）必须用
transaction模式，session模式下SET不生效，租户ID会丢失 - 别用
pg_backend_pid()+ 临时表模拟会话变量——并发场景下 PID 冲突概率高，极易写错租户
BEFORE ROW 触发器必须修改 NEW.tenant_id
只有 BEFORE ROW 类型的触发器能改写即将插入的行数据；AFTER 或 STATEMENT 级触发器做不到，强行补更新会多一次 I/O，还可能让空租户 ID 先落库。
- 函数体里必须写
NEW.tenant_id := ...，且返回NEW - 如果表字段定义为
NOT NULL，触发器没赋值就会直接报错；若允许NULL，得加IF NEW.tenant_id IS NULL THEN ...防止被覆盖 - 返回
NULL会丢弃整行插入——可用于强制校验，但一旦漏判，数据就静默消失，慎用
跨表校验唯一性时别用 COUNT(*) > 0
在触发器里做租户级唯一约束（比如限制同一租户下邮箱不能重复），用 COUNT(*) > 0 查重会扫全表、锁粒度大、性能差；EXISTS 才是正确姿势。
- 写成
IF EXISTS (SELECT 1 FROM users u WHERE u.email = NEW.email AND u.tenant_id = NEW.tenant_id) THEN ... - 务必确保
(tenant_id, email)有复合索引，否则查重变全表扫描 - SQL Server 上要用
THROW 50001, 'Email already exists', 1抛异常，只用RAISERROR不保证事务回滚
字段类型、索引、约束必须提前对齐
触发器填进去的值，和表定义不匹配是高频翻车点。租户 ID 字段不是“随便塞个字符串就行”的字段。
- 所有租户表的
tenant_id字段名、类型（TEXT/UUID/BIGINT）、是否NOT NULL必须严格一致，否则触发器无法复用 - 每个含
tenant_id的表，都得建(tenant_id, id)或(tenant_id, created_at)复合索引，否则按租户查就是慢查询 - 加
CHECK (tenant_id ~ '^[a-z0-9_]{5,32}$')这类正则约束，比事后清洗更早拦截非法值
