第 1 章 MySQL 基础概念与架构
第 1 章 · MySQL 基础概念与架构
章节摘要：评审会的第一轮往往最残酷——不是方案写错了，而是候选人根本说不清自己用的数据库是什么。本章解决三个问题：关系模型为什么统治了数据库行业五十年；MySQL 从客户端连接到磁盘落盘的那条链路上每一层在干什么；以及 InnoDB 为什么几乎总是比 MyISAM 更值得选。学完本章，你在评审会上被问"表里这个 BIGINT 为什么不用 INT"时，至少知道该往哪个方向回答。
学习目标
阅读完本章，你应当能够：
- 用"二维表、元组、属性"三个术语准确描述关系模型，并解释它与文件存储的本质区别；
- 画出 MySQL 的四层体系结构，说清一条 SELECT 从连接器走到存储引擎的完整路径；
- 面对具体的业务场景（读多写少的日志表、高并发订单表），给出存储引擎选型结论并陈述代价；
- 依据数据实际范围与精度需求为字段挑选最小够用的数据类型，识别 BIGINT 滥用、DECIMAL 误用 FLOAT 替代等典型错误；
- 区分六种约束的职责边界，理解约束放在数据库层与应用层的取舍；
- 在建表评审时，对"这张表将来会不会成为宽表"给出自己的判断依据。
核心概念速览
本章四个主题可以概括为一条链：关系模型定义了数据长什么样，体系结构定义了语句怎么被处理，存储引擎定义了数据怎么被存放，数据类型与约束定义了每个字段的行为边界。四者层层向下依赖——模型错了，后面全错；引擎选错了，性能上限被锁死。
金句：评审会上没有一个是"小问题"——每一个看似随口的字段提问，背后都是数据量翻十倍之后的事故预案。
子章节导航
1.1 关系型数据库基础：从 Codd 1970 年那篇论文讲起，把表、行、列、键、完整性这些最容易被囫囵吞枣的概念拆开讲透。这一节是全书的语义基础，后面所有"范式""外键""引用完整性"的讨论都建立在这里。评审会案例：第一版订单表被质疑"为什么用户地址存在订单表里"。
1.2 MySQL 体系结构与存储引擎：一条 SQL 进来，先过连接器、分析器、优化器，最后才落到存储引擎——这条路径决定了你优化的下手位置。本节同时讲清 InnoDB 与 MyISAM 在事务、锁粒度、崩溃恢复上的核心差异，并给出选型决策表。
1.3 数据类型与约束设计：字段类型是建表时唯一"定下来就很难改"的东西。本节按整数、小数、字符串、时间四大类梳理选型规则，再讲六种约束各自的防线位置，最后把数据库层校验与应用层校验的分工说清楚。
子章节之间的逻辑关系
三节的关系是"从面到点"：1.1 给出理论坐标系，1.2 给出引擎与架构的执行语境，1.3 落到最细的字段粒度。评审会的推进顺序也是如此——先质疑整体设计，再质疑引擎选型，最后逐字段过堂。
+----------------------+ 提供理论语言 +----------------------+ | 1.1 关系模型基础 | -------------------> | 1.2 体系结构与引擎 | | 表/键/完整性 | | SQL 执行路径 | +----------------------+ +----------+-----------+ ^ | | 字段行为由引擎特性约束 v +-------+----------------------+ 逐字段过堂 +----------------------+ | 1.3 数据类型与约束 | <------------------ | 评审意见：类型最小化 | +------------------------------+ +----------------------+
前置知识与后续延伸
本章不要求任何数据库使用经验，但你应当对"程序如何持久化数据"有直觉——比如知道把用户信息存进文本文件会在并发修改时出乱子。如果连这一层直觉也没有，建议先花一小时了解文件存储与数据库存储的差别再回来。
读完本章后，第 2 章会立刻用上你学到的类型与约束知识：设计流程、ER 模型、范式拆解，全是围绕"把表建对"展开。而第 4 章讲索引时，会反复引用 1.2 节的存储引擎分层——B+ 树长在 InnoDB 里，不复制数据本身。换句话说，本章的每个知识点都会在后面至少被调用一次，值得花力气学扎实。