标准答案
- 所有业务查询应先确定 tenant_id，索引通常也应以 tenant_id 为前缀，避免跨租户扫描和误读。
- 只查有效数据的场景要把 deleted_at 或有效状态纳入查询与索引设计，具体顺序由选择性和排序需求决定。
- 例如租户内按状态和时间分页，可考虑 tenant_id、deleted_at、status、created_at 的组合，并用计划验证。
- 软删除记录积累后应归档或物理清理，不能期待索引永远抵消历史数据增长。
- 唯一约束也要按租户和有效性语义设计，确保新建、恢复和删除之间不会产生错误冲突。
题目解析
tenant_id 与 deleted_at 通常是“每个查询都要有”的条件，它们不只是普通业务筛选。缺少任一条件都可能造成数据泄露或已删除数据复现，因此应通过数据访问层、测试和索引共同保证。
索引顺序没有固定答案。若每个租户数据量很大且未删除行占绝大多数，deleted_at 的选择性很低；若历史数据远多于有效数据，先缩小有效集可能更重要。需要以真实分布验证。
常见误区
- 把 deleted_at 条件只写在部分接口，后台任务和导出路径遗漏。
- 建立 tenant_id、deleted_at、所有字段的超宽索引，写放大远大于读收益。