2. Schema设计原则：规范化设计、反范式化设计、命名规范、数据类型选择

Schema 设计这事儿，说白了就是给数据「搭骨架」。骨架搭得好，后面存储成本、查询性能、维护难度都会省心不少。我见过太多团队一上来就写建表语句，结果半年后表结构乱成一锅粥，存储成本还居高不下。

这一节，我把多年积累的 Schema 设计原则拆成四个核心维度来讲。每个原则背后都有真实的踩坑经历，希望能帮你少走弯路。

2.1 规范化设计：别让数据「长毛」

规范化设计的核心目标就一个：消除数据冗余。冗余不仅浪费存储，还会导致数据不一致——同一个客户名称在 10 张表里出现，改的时候漏掉一张，报表就对不上了。

我个人习惯把规范化分成三个常用范式来落地：

规范化设计的另一个好处是节省存储空间。你想想看，一个客户名称如果存 100 次，每次 20 字节，那就是 2000 字节。拆成外键引用后，只需要存一个 4 字节的整数 ID。数据量上亿时，这个差距就是几十 GB。

2.2 反范式化设计：用空间换时间

规范化不是万能的。我在项目中遇到过这样一个场景：一个电商报表需要同时展示订单、商品、客户、物流四个维度的信息。如果完全按 3NF 设计，一次查询要 JOIN 七八张表，响应时间直接飙到 5 秒以上。

这时候就需要反范式化——有选择地引入冗余，减少 JOIN，提升查询性能。

常用的反范式化手段有三种：

1. 冗余字段：在订单表里冗余存储「商品名称」和「客户手机号」，避免每次查询都 JOIN 商品表和客户表。
2. 预计算列：在订单表里加一个「订单总金额」字段，由应用层在插入时计算好，避免每次统计都 SUM 子订单。
3. 合并表：把经常一起查询的父子表合并成一张宽表，比如把「商品基本信息」和「商品库存信息」合并。

这里我画了一张图，帮你快速理解规范化和反范式化的适用场景：

2.3 命名规范：好的命名是半个文档

命名这事儿，看起来是「软技能」，实际上直接影响存储成本和维护效率。我接手过一个遗留系统，表名有叫 t1 的，有叫 user_info_2020_old 的，还有叫 tmp_xxx_final_v3 的。光搞清楚每张表是干什么的，就花了两周。

我建议团队遵循以下命名规范：

2.4 数据类型选择：每一字节都要精打细算

数据类型选错了，存储成本直接翻倍。我见过一张 5 亿行的日志表，状态字段用了 VARCHAR(255) 存 0 和 1，一个字段就浪费了 250 字节。换成 TINYINT 后，整张表从 120GB 降到了 30GB。

下面是我总结的数据类型选择清单：

还有一个容易被忽略的点：字符集选择。如果业务只涉及中文和英文，用 utf8mb4 就够了，别用 utf8mb4_general_ci 以外的排序规则。我见过有人用 utf8mb4_unicode_ci，存储空间没变，但排序性能差了 10%。

2.5 实战：一个 Schema 设计案例

光说不练假把式。我们拿一个电商订单系统来实战一下：

需求： 存储订单基本信息、商品明细、收货地址。

我的设计思路：

1. 先按 3NF 拆成三张表：trade_order_main、trade_order_item、trade_order_address。
2. 字段类型精打细算：订单金额用 DECIMAL(10,2)，状态用 TINYINT，时间用 DATETIME。
3. 命名统一：主键叫 id，外键叫 order_id，创建时间叫 created_at。
4. 遇到高频查询（比如「查询订单及其商品名称」）时，在 trade_order_item 里冗余一个 product_name 字段，避免每次 JOIN 商品表。

-- 订单主表
CREATE TABLE trade_order_main (
    id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID',
    user_id INT NOT NULL COMMENT '用户ID',
    order_status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态：0-待支付 1-已支付 2-已发货 3-已完成',
    total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额',
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    INDEX idx_user_id (user_id),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

-- 订单明细表（反范式化：冗余了 product_name）
CREATE TABLE trade_order_item (
    id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '明细ID',
    order_id BIGINT NOT NULL COMMENT '订单ID',
    product_id INT NOT NULL COMMENT '商品ID',
    product_name VARCHAR(100) NOT NULL COMMENT '商品名称（冗余）',
    quantity INT NOT NULL COMMENT '数量',
    price DECIMAL(10,2) NOT NULL COMMENT '单价',
    INDEX idx_order_id (order_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';