1. 模式设计（Schema Design）

• Schema Design: Normalize to reduce redundancy; denormalize for read performance
• 规范化（Normalization）：想象你把所有信息都堆在一个表里，会出现重复字段、重复数据。比如客户信息和订单信息都在同一个表里，同一个客户下的每个订单都要重复写客户姓名和地址。规范化就是把客户拆到 “Customer” 表，把订单拆到 “Order” 表，只在订单里存客户的外键（比如 customer_id），这样数据不会冗余，也不容易出错。
• 反规范化（Denormalization）：有时候你很频繁地要同时读客户和订单信息，如果每次都要做 JOIN，就会比较慢。反规范化就是在订单表里多存几个常用的客户字段（比如客户姓名），省去 JOIN 的开销，查询更快，但写入或更新时要更谨慎，因为数据会有多份。

2. 索引（Indexing）

• Indexing: Improves query speed; target high-selectivity columns
• 把索引想象成书的目录：如果没有目录，你要查某个关键词，需要一页页翻；有了目录（比如按关键词排序），就能迅速定位到对应页码。数据库的索引原理也是一样，底层通常用 B 树结构，把列的值和指向对应行的指针存起来。
• 高选择性：如果一列的值几乎都是相同（比如性别只有“男”“女”两种），做索引效果不明显；如果一列值千差万别（比如身份证号、手机号），索引就能快速过滤到所需行。所以要优先给“高选择性”的列建索引。

3. 事务（Transactions）

• Transactions: Atomic groups of operations to maintain integrity
• 事务就像一个“事务袋”：把一组相关操作（比如扣款、下单、减库存）放进去，要么“全部放行”（Commit），要么“全部撤回”（Rollback）。
• 四个 ACID 特性保障：
  • Atomicity（原子性）：事务内的操作是整体，要么全做，要么全不做。
  • Consistency（一致性）：事务执行前后，数据库都必须满足预先定义的规则（如外键约束、唯一索引等），不会出现不合法的数据状态。
  • Isolation（隔离性）：并发执行时，每个事务好像“隔离”在自己的世界里，不会被其他事务的中间状态干扰。
  • Durability（持久性）：一旦提交，数据就写入磁盘，即使机器突然宕机也不会丢失。

4. 连接与关系（Joins & Relationships）

• Joins & Relationships: Combine data across tables vs embedding data in documents
• 在关系型数据库中，表与表之间通过外键关联。要查询相关联的数据，就用 JOIN。
  • INNER JOIN：只返回两表中“匹配”的行，类似两个集合的交集。
  • LEFT JOIN：以左表为基准，左表所有行都保留，右表没有匹配的部分显示为空（NULL）。
  • RIGHT/FULL JOIN：同理，保留右表或两表所有行。
• 在文档型数据库（如 MongoDB）中，可以**嵌入（embed）**相关数据到同一个文档里。比如把客户地址直接存在客户文档里，查询时就不需要再去“关联”另一个集合了，读性能更好，但写入时可能需要更新多个文档。