Schema 与数据类型设计

一、Schema 设计的第一性原理

1. 数据库的本质约束

关系型数据库本质上是：

由此引出三个稳定结论：

  1. **IO 成本远高于 CPU 成本**
  2. **顺序访问远快于随机访问**
  3. **存储密度直接影响性能**

所有 Schema 设计规则，都是这三点的自然推论。

2. 局部性原理与 Schema 设计

局部性原理包括：

Schema 设计的目标之一，就是：

让“逻辑上相邻的数据”，在“物理上也尽可能相邻”

这直接影响：

二、数据类型选择的设计模型

1. 数据类型选择的通用原则

原则 1：更小的通常更好

前提不是“越小越好”，而是：

在满足业务语义和取值范围的前提下，选择最小的表达形式

原则 2：简单优于复杂

Schema 的复杂度，会被：

成倍放大。

2. NULL 的设计成本

NULL 并不是“没有值”，而是：

因此：

3. 字符串类型的取舍模型

CHAR / VARCHAR / TEXT 的本质区别

选择依据不是“最大长度”，而是：

4. 时间类型的语义边界

时间类型的选择，本质是：

你是在记录认为“绝对不变”的事实，还是“环境相关”的事件

三、主键与索引的架构取舍

1. 主键的核心职责

主键不是业务概念，而是：

因此，主键的核心目标是：

稳定、有序、紧凑

2. 代理主键 vs 自然主键

代理主键

自然主键

在工程实践中：

代理主键几乎总是更优的基础选择

3. 为什么随机字符串主键是性能杀手

这是局部性原理在 Schema 层面的直接体现。

四、范式、反范式与数据冗余

1. 范式化的价值

代价是：

2. 反范式的工程动机

反范式不是“偷懒”，而是：

典型场景包括：

3. 冗余的治理前提

所有冗余设计，必须回答三个问题：

  1. 谁是权威数据源
  2. 通过什么机制保持一致
  3. 出现不一致时如何修复

否则，冗余就是技术债。

五、Schema 演进与治理

1. ALTER TABLE 的真实成本

ALTER TABLE 的本质是：

Schema 变更不是 DDL 操作，而是：

一次系统级变更行为

2. 演进策略

目标不是“快”，而是“可控”。

六、结语：Schema 是系统设计的一部分

Schema 不是静态结构，而是：

一个好的 Schema 设计，体现的不是技巧，而是：

对系统本质约束的尊重

关联内容（自动生成）