配速记页 05-database 使用。你的实战强区，本页目标是「经验术语化 + 盲区补强」。
范式不是教科书洁癖，它解决的是数据冗余引发的三类异常：
本质：一个关系里塞了多件事实（学生的事实 + 系的事实），一件事实的每份拷贝都是不一致的机会。范式的哲学：一个关系 = 一个事实类型（「原子事实」思想，血统可追到关系代数之父 Codd）。
BCNF 的通俗判据：表里不要存「与键无关、却互相决定」的列。2NF/3NF 修非主属性，BCNF 连主属性的部分/传递依赖也修。
规范化把 JOIN 拆得满天飞，读多写少的场景（报表、首页）查询成本爆炸。反规范化=主动引入可控冗余换取读性能：
判据一句话：写频率 × 一致性敏感度 < 读频率 × JOIN 成本，才值得反规范化。ERP 报表宽表、支付对账快照表都是正当反规范化。案例题答「反规范化」必须主动提代价（一致性维护、触发器/应用层同步），不提代价扣分。
CAP 说的不是「三选二」的菜单，而是：分区（P）发生时，一致性（C）与可用性（A）不可兼得。P 不是选项——网络分区在分布式里必然发生，你只能选 C 还是 A：
选 C（CP）：分区时拒绝写入（不可用），保住一致性。ZooKeeper 选主期间不可用。 选 A（AP）：分区时继续服务，各分片数据暂时不一致，事后收敛。Eureka 宁可给过期地址。
BASE 是 AP 路线的收尾：Basically Available + Soft state + Eventually consistent。最终一致不是妥协，是工程选择——「账单可以晚 2 秒到，不能不服务」。
（注意：C 这里指线性一致性/强一致，不是 ACID 里的 C。考试按上述主流口径答即可。）
2PC（数据库层）：协调者问所有参与者「能提交吗」（Prepare），全部 YES 才 Commit。
TCC（应用层补偿）：Try（冻结资源：预扣余额）→ Confirm（真扣）→ Cancel（解冻）。
Saga（长事务拆解）：把长流程拆成本地事务序列，每步配一个补偿动作（订了票退票、扣了款退款）。
演进逻辑：从「数据库替你保证」到「业务自己设计补偿」——一致性从基础设施层逐级上移到业务层，换来可用性和性能。你的支付系统里「下单-扣款-发货-对账」链路，本质就是 Saga + 对账兜底。
| 类型 | 牺牲了什么 | 换来了什么 | 问题域 |
|---|---|---|---|
| KV(Redis) | 复杂查询 | 极致简单=极致快 | 缓存/会话/排行榜 |
| 列族(HBase) | 事务、灵活模式 | 海量写、水平扩展 | 时序/日志/物联网 |
| 文档(Mongo) | 跨文档事务弱 | 模式自由 | 内容/画像/多态 |
| 图(Neo4j) | 水平扩展难 | 多跳关系查询 | 推荐/风控/反欺诈 |
一句话总结 NoSQL 运动：对单一查询模式做到极致，把关系库的「什么都能干」拆成「各干各的」。NewSQL（TiDB/OceanBase）则是回摆：既要 SQL 语义又要水平扩展。