多租户系统中租户字段设计需权衡隔离强度、查询性能与扩展成本：tenant_id 必加且类型和索引策略影响性能上限；硬隔离（库 /Schema 级）无需 tenant_id 但运维复杂，软隔离（表级）须全员非空 + 联合索引 + 显式 JOIN 过滤；需预留 is_deleted、tenant_status 等字段并避免拼接主键。
多租户系统中，租户字段设计不是“加个 tenant_id 就完事”，关键在隔离强度、查询性能、扩展成本三者间的取舍。选错方案，轻则慢查频发，重则数据越界、迁移踩坑。
tenant_id 必加，但类型和索引策略决定性能上限
几乎所有多租户表都需显式 tenant_id 字段。重点不在“有没有”，而在“怎么建”：
- 类型对齐业务规模 ：中小系统用 BIGint（避免 INT 溢出）；超大规模或需跨库分片时，可考虑 char(32) 存 UUID 或业务 编码（如“org-7a2f”），便于后续逻辑分片或租户迁移
- 联合索引优先于单列索引：WHERE tenant_id = ? AND status = ? ORDER BY created_at 的高频查询，应建 (tenant_id, status, created_at) 联合索引，而非仅 tenant_id 单列索引——否则 mysql 可能无法高效下推 tenant_id 过滤条件
- 避免在 tenant_id 上做函数操作：比如 WHERE SUBSTRING(tenant_id, 1, 3) = ‘org’ 会令索引失效；如需分类标识，单独加 tenant_type 字段更可控
硬隔离 vs 软隔离：字段设计要匹配部署模型
隔离级别直接决定字段冗余度与校验复杂度：
- 数据库 级硬隔离（每租户独立 DB）：表结构无需 tenant_id 字段，但应用层必须严格 路由 ；适合 金融 类强合规场景，缺点是运维成本高、跨租户分析困难
- Schema 级隔离（同 DB 不同 Schema）：仍无 tenant_id 字段，但需在连接池 /ORM 层动态切换 schema；兼容性好，但 postgresql 支持佳，MySQL 对 schema 切换支持弱，慎用
- 表级软隔离（主流选择）：所有业务表含 tenant_id，且 必须为非空（NOT NULL）+ 默认约束（default CURRENT_TENANT）或应用层强校验；配合行级安全策略（如 PostgreSQL RLS 或 MySQL 8.0+ CHECK + 视图）可补强隔离
关联查询优化：租户上下文不能靠 JOIN 传递
常见错误是主表带 tenant_id，关联表不带，靠 JOIN 推导租户归属——这既不可靠（可能漏过滤），又难优化：
- 所有参与关联的业务表，只要属于租户维度，必须自带 tenant_id；例如 order 表和 order_item 表都要有 tenant_id，且外键不指向 tenant_id（避免反范式），而用普通业务外键（如 order_id）
- JOIN 条件必须显式包含 tenant_id 对齐：ON o.id = oi.order_id AND o.tenant_id = oi.tenant_id；否则跨租户数据可能意外混入（尤其当 optimizer 重排 JOIN 顺序时）
- 慎用视图 封装 多租户逻辑：若视图里写死 tenant_id 过滤，会导致无法复用；建议用参数化视图（PostgreSQL）或应用层拼接 WHERE，确保灵活性
预留扩展字段：为未来隔离升级留余地
初期选软隔离不等于永远软隔离。字段设计要防“一步到位陷阱”：
- 加 tenant_id 的同时，加 is_deleted（软删）、tenant_status（如 active/archived）等状态字段，避免后期加字段引发全表锁或历史数据迁移
- 主键避免用自增 ID + tenant_id 拼接：如 CONCAT(tenant_id, ‘-‘, id)，看似隔离实则破坏索引局部性、影响范围查询；推荐 Snowflake ID 或 ULID，全局唯一且有序
- 敏感操作字段留痕：created_by_tenant、updated_by_tenant 比单纯 created_by 更明确责任边界，审计与问题回溯更直接
