面试题：后端
后端工程师岗位相关的接口设计、服务端基础、并发、存储和稳定性面试准备。
关系型数据库适合解决什么问题，什么时候应考虑文档、键值或搜索型存储？
关系型数据库擅长管理结构明确、关系复杂且需要事务约束的业务事实；文档、键值和搜索型存储分别在模式灵活、按 Key 高吞吐和全文检索场景更有优势，通常是互补而不是互相替代。
一对一、一对多、多对多关系在表结构中通常怎样建模？
关系建模要先确定实体边界、关系基数和生命周期：一对一通常用唯一外键拆分可选字段，一对多把外键放在多的一侧，多对多则用关系表表达关联自身的属性与约束。
第一、第二、第三范式分别解决什么数据冗余和更新异常问题？
范式的目标是让一个事实尽量只在一个地方维护：第一范式消除重复组，第二范式消除对联合键的部分依赖，第三范式消除非主键字段之间的传递依赖，从而降低新增、更新和删除异常。
什么情况下应该反范式化，怎样避免冗余字段逐渐失真？
反范式化适合用可控冗余换取读性能、历史快照或跨服务查询成本下降；前提是明确事实源、更新触发点、校验与重建路径，而不是复制字段后期待它们自然保持一致。
主键应使用自增 ID、UUID、雪花 ID 还是业务编码，分别有什么索引和业务影响？
主键方案要同时考虑全局唯一性、写入局部性、索引宽度、可暴露性和生成可用性：自增 ID 写入友好，UUID 去中心化但随机且较宽，雪花 ID 兼顾排序和分布式生成，业务编码通常不应承担主键职责。
自然键和代理键分别适合什么场景，为什么业务字段通常不适合直接做主键？
自然键来自现实业务属性，例如国家代码或不可变标准编码；代理键是为技术关联生成的无业务含义标识。多数业务表采用代理键作主键，再用唯一约束保护真正的业务身份。
created_at、updated_at、deleted_at、version 等审计字段怎样设计才方便排查和迁移？
审计字段应服务于时间定位、并发控制、数据生命周期和迁移验证：统一时间语义与时区，明确谁维护字段，并让软删除和版本变化能被查询、索引和日志可靠使用。
软删除会怎样影响唯一索引、查询条件和数据恢复？
软删除保留数据和审计痕迹，但会把“当前有效数据”和“历史数据”混在同一张表中，因此必须同步处理默认查询、唯一性、索引选择、恢复冲突和数据保留期限。
多租户数据隔离可以放在行、库、Schema 还是集群，如何选择？
多租户隔离需要在成本、隔离强度、运维复杂度、合规要求和扩展方式之间取舍：共享表按行隔离成本最低，独立库或集群隔离最强，Schema 是部分数据库中的中间方案。
NOT NULL、DEFAULT、CHECK、UNIQUE、FOREIGN KEY 各自适合把哪些规则放进数据库？
数据库约束适合承载所有写入路径都必须满足的基础事实：非空、默认值、取值范围、唯一性和引用完整性。它们与应用校验互补，不能只靠接口层保证。