数据库 | 看这一篇就够了！最全MySQL数据库知识框架！

原创

kfaino

修改于 2023-11-03 12:18:12

3780

修改于 2023-11-03 12:18:12

大家好！

作为一名程序员，每天和各种各样的“数据库”打交道，已经成为我们的日常。当然，立志成为一名超级架构师的我，肯定要精通这项技能。咳咳！不过饭还是要一口一口吃的，“数据库”这个内容实在太大了，我们今天还是以关系型数据库的代表“MySQL说起，现如今，MySQL已经变得无处不在，从初创公司的小型项目到大型企业的核心系统，都在使用。

那么，作为开发者，如何系统地学习和掌握MySQL呢？

本文的核心目标有两个：

一是为你呈现一个结构化的MySQL知识框架；

二是，确保你不仅仅是“知其然”，还要“知其所以然”。

为了让这个知识框架更加直观，我画了一个思维导图，你可以看下：

如果你准备好深入MySQL的世界，那我们就开始吧！

通关要求

在学习的过程中，仅仅理解概念是不够的，我们还需要将其付诸实践，验证所学并巩固。这也是“通关要求”存在的原因。下面是每个章节的挑战任务，成功完成它们，就像过关斩将，证明你已经真正掌握了这部分内容。

入门MySQL

实操验证标准：

会安装配置MYSQL
创建一个MySQL实例。
完成基础的CRUD操作和一些常用的指令。

面试通关验证标准：

创建utf8和utf8mb4 这两个字符串编码的数据库有什么区别？utf8 的字符串编码会碰到什么问题？

数据库设计

实操验证标准：

设计一个简单的电商数据库模型，包含商品、用户和订单三个表。
数据模型满足范式。

面试通关验证标准：

你在项目中有自己设计表结构吗？一般会怎么去设计一张表的？

我在这里为大家举个例子，在思考和回答这个问题建议结合自身熟悉的业务场景来。好，我们开始吧！

👦 候选者: 面试官你好！我大部分是负责订单业务这块的，一帮我们这边在接到一个明确的需求，然后评审设计，如果碰到需要新增表的情况。我们会把完整的数模进行重新梳理关系。然后按照业务场景和需求进行抽象。具体思考过程如下：

1. 明确业务场景和需求

用户下单
订单支付
发货管理
订单状态变更（如：待支付、已支付、已发货、已完成、已取消等）
退货申请与处理

2. 确定主要实体和属性

用户（User）：用户ID、用户名、地址等。
商品（Product）：商品ID、商品名称、商品价格、商品库存等。
订单（Order）：订单ID、下单用户、总金额、订单状态、下单时间、支付时间、发货时间、完成时间等。
订单详情（OrderDetail）：关联商品、购买数量、商品当前价格等。
退货申请（ReturnApplication）：申请原因、申请时间、处理状态、处理结果等。

3. 确定实体之间的关系：

用户与订单：一对多。
商品与订单详情：一对多。
订单与订单详情：一对多。
订单与退货申请：一对多。

4. 转化为表结构

User 表：

CREATE TABLE `User` (
    `userID` INT PRIMARY KEY AUTO\_INCREMENT,
    `username` VARCHAR(255) NOT NULL,
    `address` TEXT,
    ……
);

Product 表：

CREATE TABLE `Product` (
    `productID` INT PRIMARY KEY AUTO\_INCREMENT,
    `productName` VARCHAR(255) NOT NULL,
    `price` DECIMAL(10, 2),
    `stock` INT,
    ……
);

Order 表：

CREATE TABLE `Order` (
    `orderID` INT PRIMARY KEY AUTO\_INCREMENT,
    `userID` INT,
    `totalAmount` DECIMAL(10, 2),
    `status` ENUM('pending', 'paid', 'shipped', 'completed', 'canceled'),
    `orderTime` DATETIME,
    `paymentTime` DATETIME,
    `shippingTime` DATETIME,
    `completionTime` DATETIME,
    ……
    FOREIGN KEY (`userID`) REFERENCES `User`(`userID`)
);

OrderDetail 表：

CREATE TABLE `OrderDetail` (
    `orderDetailID` INT PRIMARY KEY AUTO\_INCREMENT,
    `orderID` INT,
    `productID` INT,
    `quantity` INT,
    `currentPrice` DECIMAL(10, 2),
    ……
    FOREIGN KEY (`orderID`) REFERENCES `Order`(`orderID`),
    FOREIGN KEY (`productID`) REFERENCES `Product`(`productID`)
);

ReturnApplication 表：

CREATE TABLE `ReturnApplication` (
    `applicationID` INT PRIMARY KEY AUTO\_INCREMENT,
    `orderID` INT,
    `reason` TEXT,
    `applicationTime` DATETIME,
    `status` ENUM('pending', 'approved', 'rejected'),
    ……
    FOREIGN KEY (`orderID`) REFERENCES `Order`(`orderID`)
);

5. 优化设计

第一轮我们会把这些属性头脑风暴然后一一都列出来。判断它们是否符合范式。若一张表字段过多就要拆表了。表设计是个很复杂的活计，一般都是专门的DBA进行设计。当然也会有我们程序员的参与。