很多人第一次接触编程时都写过文件读写：把用户注册信息一行一行写进 user.txt，再从里面一行一行读回来。等到数据多了、查询复杂了、要并发了，这一套马上就撑不住。于是大家会不约而同地指向同一个问题——为什么不直接用文件存数据，非要搞一个"数据库"出来？ 这节课我们就从这个问题出发，把"数据库"这三个字掰开揉碎讲清楚，再一路讲到 MySQL 里库和表的关系、SQL 的四大分类，以及怎么把自己的一台机器连上一个数据库服务器。

这是 MySQL 系列的第一篇，目标是把"地基"打牢。读完你会清楚地知道：数据库和数据库管理系统有什么区别、为什么大家天天在说"关系型"，以及你在命令行按下的那些 create database、select 到底是哪一类 SQL。

你应该有的知识准备

这一篇不需要任何数据库经验。你只要满足下面这两条就够：

  • 会基本使用终端/命令行：能在 Windows 的 CMD/PowerShell 或 Linux 的终端里敲命令。MySQL 命令行的使用本质上就是在终端里输入指令。
  • 对"表"有点直觉：哪怕只是见过 Excel 里的"表格"，列是字段、行是一条记录这个印象也能帮你大幅降低理解成本。

如果你从没在终端里连过任何服务，也没关系，这一篇会带你一步步走。

什么是数据库：为什么不能只用文件

先给"数据库"一个准确的定义，因为它和"数据库管理系统"是两个不同的词，很多人混着用，容易出岔子。

数据库（Database，缩写 DB）是一个非常朴素的词：它指"按一定结构组织起来、可以被高效存储和检索的数据集合"。你可以把它粗略想象成"一个装着有组织数据的容器"。

而数据库管理系统（Database Management System，缩写 DBMS）是"管理这些数据库的那套软件程序"。MySQL、Oracle、PostgreSQL、SQL Server 这些，全都是 DBMS。换句话说，数据库是"数据本身"，DBMS 是"管数据的软件"。我们常说的"装一个 MySQL"，装的其实是一个 MySQL 的 DBMS，这个程序运行起来之后，才能在这个 DBMS 里去建数据库、建表、存数据。

那问题来了：既然文件也能存数据，为什么非要多此一举地搞数据库？一句话：文件能"存"，但不好"管"。 具体而言，用文件保存数据有四个硬伤：

  • 文件的安全性问题。文件谁能读、谁能改、密码放哪、权限怎么控制，都要你自己操心。业务稍微复杂一点，权限就管不过来，数据裸奔在硬盘上。
  • 文件不利于数据查询和管理。你要从几十万条里"查名字叫张三的"，得自己写代码遍历，速度慢、写法乱。而且文件格式一乱，想加个字段、删个字段都困难。
  • 文件不利于存储海量数据。海量数据不仅仅是"大"，还涉及怎么分片、怎么建索引加速、怎么在高并发下不卡死，这些文件都搞不定。
  • 文件在程序中控制不方便。你今天用这个格式写，明天换个人用另一个格式读，兼容性全崩。程序需要的是稳定统一的接口，文件给不了。

为了解决这四个问题，专家们设计出了更善于管理数据的软件——也就是 DBMS，通过它来更高效地管理数据。历史地里，数据库的水平被大家普遍看作是衡量一个程序员水平的重要指标：一个能设计出合理表结构、写出高效 SQL 的人，和一个只会堆文件的程序员，面对同样规模的数据，产出天差地别。

再补最后一个常识：数据库这种"有组织的数据"最终存在哪里？答案是磁盘和内存。磁盘（硬盘）负责持久保存——关机了数据还在；内存负责临时加速——正在被高频读写的热数据先放内存里加快速度，但一断电就没了。DBMS 的任务之一，就是在这两者之间合理地调度数据。

思考题 1：现在有 100 万条用户记录要存，给你两个选择——用 CSV 文件存，还是用数据库存？说说你的理由。

答案与详解：应该用数据库。理由可以从文件四大缺点的任何一个切入：

  • 查询：CSV 你要查"某个用户"必须写程序逐行扫描，100 万条最坏扫 100 万次；数据库建立索引后（如主键索引）可以快到接近一次定位。
  • 并发：多个程序同时往同一个 CSV 写，会出现互相覆盖、数据错乱；数据库有锁机制和事务保证一致性。
  • 结构变更：CSV 文件格式写死了，以后想加个"年龄"字段，老数据全都要迁移；数据库用一条 alter table 就能加列。
  • 安全：CSV 无法精细控制"谁能读哪个字段哪几行"；数据库可以做用户权限、列级权限。 所以文件适合"数据量小、结构简单、几乎没有并发"的场景；一旦规模和数据管理要求上来，数据库是必然选择。

主流数据库巡礼

既然 DBMS 是一类软件，市面上就有不少选手。学习时知道它们各自的长处和短板，以后选型才不会一头雾水。这里按主流常见程度介绍几个：

  • SQL Server：微软的产品，.NET 程序员的最爱，常见于中大型项目，尤其多见于微软生态的 Windows 企业应用里。
  • Oracle（甲骨文）：甲骨文公司的旗舰产品，适合大型项目、复杂的业务逻辑。它功能极其强大，但偏"重型"，并发能力一般来说反而不如 MySQL 灵活（在极致并发吞吐上各有取舍）。
  • MySQL：号称"世界上最受欢迎的数据库"，同样属于甲骨文。并发性好，处理简单的 SQL 效率很高，但不适合特别复杂的业务逻辑，主要用在电商、SNS、论坛这类读多写多的场景，和 Web 开发是黄金搭档。
  • PostgreSQL：由加州大学伯克利分校计算机系开发的关系型数据库。它是开源且免费的，无论是私用、商用还是学术研究，都可以免费使用、修改和分发。功能非常完整，近年来越来越多企业和开发者切换到它。
  • SQLite：一款轻型的数据库，是遵守 ACID 的关系型数据库管理系统，它包含在一个相对小的 C 库中。它的设计目标是嵌入式——很多嵌入式产品都在用它，占用资源非常低，在嵌入式设备里可能只需要几百 K 的内存就够了。手机 App 里"本地存储"很多就是它。
  • H2：一个用 Java 开发的嵌入式数据库，它本身只是一个类库，可以直接嵌入到应用项目里。Java 生态做单元测试时经常临时开一个内存里的 H2 来模拟数据库。

可以看到，MySQL 的特点是"简单好用、并发好"，所以它成了无数初学者和 Web 项目的首选。我们这一系列就以它为例。

有一个细节值得先立起来：上面几乎所有产品都自称"关系型数据库"。这个词我们马上要解释清楚，因为它是理解表结构的基础。

思考题 2：分享一下你的印象——为什么说 MySQL"不适合做特别复杂的业务逻辑"，而 Oracle 适合？

答案与详解：这是一个非常经典的经验总结，不是绝对真理，而是取向差异：

  • MySQL 的设计理念偏向"轻快、简单、响应快"，它对高并发简单查询优化得极好（例如电商秒杀的商品查询），但对极其复杂的嵌套查询、复杂的分析型查询，优化器能力不如 Oracle 老练。
  • Oracle 功能极其厚重：强大的 PL/SQL、复杂的分析函数、成熟的优化器、完善的灾备/调优体系，能扛"复杂业务逻辑"，但资源开销大、配置复杂、门槛高。
  • 所以口诀是：简单的 SQL、高并发 → 挑 MySQL；复杂业务、企业级分析 → 挑 Oracle。当然这是经验法则，同一个场景往往不止一种正确答案。

关系型数据库：行、列、表、库

想让"关系型"这个高频词落地，你得先看清它最核心的那套东西：表。

表（Table）可以理解成一张二维的表格，它由横向的行（Row）和纵向的列（Column）构成。一个行也叫一条"记录"（Record），一列也叫一个"字段"（Field）。一个学生表可能是这个样子：

id（列/字段）name（列/字段）gender（列/字段）
1（第一行的 id 值）张三男
2李四女
3王五男

横向一行是"一个学生的完整信息"--一条记录；纵向一列是"所有学生的某一个属性"--一个字段。表结构在一开始创建时就用"列的类型"定好了：id 是整数，name 是可变长字符串，gender 是短字符串。这种"一行描述一个实体、一列描述一个属性、结构固定"的组织方式，就是关系型（Relational）的核心——数据之间通过"主键、外键"等各种关系联系起来，所以叫关系型数据库。与之相对的非关系型数据库（NoSQL，如 Redis、MongoDB）则不用这种固定表格结构，各有千秋，这里先点到为止，本系列主要讲关系型。

有了表，就要有"库"。数据库服务器（DBMS 程序）可以同时管多个数据库（也叫库、schema），每个库里可以建多张表。它们的从属关系是这样的，请你务必刻进脑子：

数据库服务器（DBMS 程序）        -- 一台机器上跑的这个 MySQL 程序
   └── 数据库（库/schema）       -- 一般每个应用一个库
         └── 表（table）          -- 库里放多张表，每张表存一类实体
               └── 行 / 列        -- 表里的数据：一条记录 / 一个字段

所以库和表的层次天然是"多对多 → 一对多 → 一对一"：一个服务器管多个库，一个库装多张表，一张表有若干行和列。开发人员一般会针对每一个应用创建一个数据库，再在库里为各类实体（学生、订单、商品……）各建一张表。这就是"服务器—数据库—表"三层关系。

思考题 3：现在有"学生管理系统"和"图书管理系统"两个项目，它们该用几个数据库、几张表？

答案与详解：一般用两个数据库——每个项目一个库（如 student_sys、library_sys），互不干扰。然后在 student_sys 里建比如 student（学生）、course（课程）这样的多张表；在 library_sys 里建 book（图书）、reader（读者）等多张表。原因是把不同应用的数据隔离到不同库，便于权限管理、备份和迁移。至于每个库里"建几张表"，取决于你要存几类实体，一般一条类型一张表。

安装 MySQL 与连接服务器

概念说清楚了，就该动手了。装 MySQL 有几种常见路径：比如在 CentOS 7 里通过 yum 安装 MariaDB（MariaDB 是 MySQL 的一个分支，命令习惯几乎一致）；在 Windows 下安装 MySQL 5.7 则通过官方安装包。具体安装步骤因环境而异、不停在变，这里不展开细节，重点讲"装好之后怎么连上它"。

注意：连接 MySQL 用的是典型的客户端—服务器（Client-Server） 架构。服务器是那台真正装着数据、跑着 MySQL 服务的机器；客户端是你用来"发指令过去"的程序，比如 MySQL 自带的一个命令行工具 mysql。它们的对话流程就是：你打开客户端，告诉它连哪台服务器，服务器验证你的账号密码，通过后建立起一个会话，你就在这个会话里敲 SQL。

连接的命令长这样：

mysql -h 127.0.0.1 -P 3306 -u root -p
#    │        │        │    │   └─ -p：回车后让你输密码
#    │        │        │    └─ -u：指定用户名，root 是 MySQL 默认超级管理员
#    │        │        └─ -P：指定端口号，MySQL 默认端口就是 3306
#    │        └─ -h：指定服务器主机地址，127.0.0.1 代表本机
#    └─ mysql：MySQL 自带的命令行客户端程序

逐项拆解这四个参数：

  • -h：连接的主机名。如果你不写 -h，默认就是连接本地（也就是本机）。
  • -P：端口号。如果你不写 -P，默认就是 3306。端口相当于"这台机器上 80 号大门"，不同软件用不同端口各自开工互不打架。
  • -u：用户名。root 是安装时创建的超级管理员账号。
  • -p：密码。敲下回车后，终端会提示你输入密码，输入时不会回显（屏幕上不显示你按的字符，这是正常的），输完再回车。

连接成功后，你会看到类似下面的一大段欢迎信息：

Enter password: ****
Welcome to the MySQL monitor.  Commands end with ; or \g.
--                                          ^          ^
--                                          分号        \g 是分号的另一种写法，都能结束一条语句
Your MySQL connection id is 2
Server version: 5.7.21-log MySQL Community Server (GPL)
...（版权信息省略几行，不影响使用）...
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
--      ^
--      这就是 MySQL 命令行提示符，出现它说明你已经在 MySQL 的交互环境里了

注意高亮的两点。第一，欢迎语里那句 "Commands end with ; or \g" 直接点出了我们后面要强调的规则——每一条 SQL 语句要用分号 ;（或 \g）结尾。第二，最下面那个 mysql> 是命令提示符，看到它，就表示当前已经连接成功，你可以输入 SQL 了。如果中途某条语句写错了想放弃，可以输入 \c 清除当前这条输入。

思考题 4：我现在在虚拟机里"192.168.1.50"这台机器上装了 MySQL，端口特意改成了 3307，用户名是 admin。我想从本机连过去，命令应该怎么写？

答案与详解：

mysql -h 192.168.1.50 -P 3307 -u admin -p

因为服务器不在本机，所以 -h 必须写明目标 IP；因为端口被改成 3307，所以 -P 必须写 3307（不写就默认 3306，会连不上）；用户名是 admin，-u admin；-p 表示接下来输密码。一个都不能省。

服务管理：怎么启动、停止 MySQL

连接之前，MySQL 服务得先运行起来。在 Windows 上，最简单的方法是：按 Win + R，输入 services.msc 回车，打开服务管理器，在左侧栏找到 MySQL 对应的服务，就可以通过上面的"启动、停止、暂停、重新启动"按钮来管理它的状态。这台机器上的 MySQL 程序，就是我们前面说的"数据库服务器"（DBMS），它没启动，客户端连谁去？

这里要建立一个重要的认知：所谓"安装数据库服务器"，其实只是在你的机器上安装了一个"数据库管理系统程序"。这个程序本身不存储是"某一份"数据，而是"能管理多个数据库"的总管。你在服务管理器里启停的，正是这个总管程序。

第一次建库建表：把数据存起来

连接好、服务也跑起来了，我们来走一遍完整的最小闭环：建库 → 用库 → 建表 → 插数据 → 查数据。这套流程请你亲手敲一遍，它是后面所有内容的骨架。

-- 1. 创建一个数据库，名字叫 helloworld
create database helloworld;
 
-- 2. "使用"这个库，告诉 MySQL 后面我都在 helloworld 这个库里操作
use helloworld;
 
-- 3. 在这个库里创建一张学生表 student，并定义三列
create table student(
    id     int,          -- 列 id，类型是整数 int
    name   varchar(32),  -- 列 name，类型是可变长字符串，最多 32 个字符
    gender varchar(2)    -- 列 gender，类型是可变长字符串，最多 2 个字符（如"男"/"女"）
);
 
-- 4. 向表里插入数据：给 id、name、gender 三列分别赋值 1、'张三'、'男'
insert into student (id, name, gender) values (1, '张三', '男');
insert into student (id, name, gender) values (2, '李四', '女');
insert into student (id, name, gender) values (3, '王五', '男');
 
-- 5. 查询表中的所有数据：* 表示"所有列"
select * from student;

这几条命令恰好串起了我们后面要讲的 SQL 四大分类：前三条 create、use、create(表) 属于维护结构的 DDL，插入的 insert 属于写数据的 DML，最后的 select 属于查询的 DQL。先留个印象，下一节专门拆。

关于第三条建表，有几个细节值得展开：

  • varchar(n) 表示可变长字符串，括号里的 n 是最多存几个字符。varchar(2) 大多用来存"男/女"这种短值，表结构在创建时就决定了每列"装什么类型"。
  • varchar 后面的数字是"最多字符数"，存"张三"是 2 个字符，没问题。

执行完第五步 select * from student; 后，MySQL 会把表内容打成一张 ASCII 表格打印出来，你就能看到刚插入的 3 行数据安安静静躺在表里。这说明"建库、建表、插数、查数"这条最小链路已经走通了。

思考题 5：如果不先执行 use helloworld; 就直接 create table student(...)，会发生什么？怎么才能不用 use 也能在指定库里建表？

答案与详解：不执行 use，MySQL 不知道你要在哪个库里建表，会在你建表时报类似 No database selected（没有选择数据库）的错误。两个解决办法：

  • 先执行 use 库名; 再建表；
  • 或者把"库名"作为前缀写进建表语句：create table helloworld.student(...); —— 用 库名.表名 这种带库名的写法，就能在不 use 的情况下明确指定目标库。

边界与坑：大小写、分号、库表层次

数据库新手最容易栽跟头的几个"小地方"，这里一次性讲透，踩坑率能大幅下降。

每条 SQL 都要以分号结尾

你命令里每条完整的 SQL 语句必须以分号 ;（或 \g）结尾。原因在于 MySQL 的客户端是"一行一行读的"，它并不知道你的语句到哪里结束，只有看到分号才认为"这条命令到这里为止，可以执行了"。如果你忘打分号直接回车，MySQL 会认为这条命令还没写完，继续等你的下一行（提示符会变成 ->），输入也会"悬着"不执行。所以口诀是：一条 SQL 语句结束，分号结尾。像 mysql> 提示符本身是交互环境，不需要打分号，但里面的 SQL 都要打。

大小写：库名、表名的敏感性因系统而异

大小写是 MySQL 里特别容易踩的坑，规则是"关键字不敏感、库表和列名视情况"：

  • SQL 关键字本身不区分大小写：SELECT、select、SELECT 随便写都能执行。但约定俗成的写法是关键字全大写、表名列名小写，这样可读性好。
  • 数据库名和表名是否区分大小写，取决于底层操作系统。在 Windows 上默认表名/库名不区分大小写（student 和 STUDENT 等同）；在 Linux 上默认是区分大小写的（student 和 STUDENT 是两个不同的表）。两者由 MySQL 的一个配置项 lower_case_table_names 控制。所以同一个项目在 Windows 上跑得好好，搬到 Linux 上就报"表找不到",往往是大小写不一致导致的。跨平台时最好统一用小写表名。
  • 列名不区分大小写（NAME 和 name 在绝大多数默认排序规则下等同），但值呢，取决于列的字符集排序规则——库、表、列的字符集不统一，很容易出乱码，这个我们后续文章会细讲。

一句话总结这套坑：关键字随便大小写但建议大写，库名表名建议一律小写以保证 Windows/Linux 一致，列名我们也约定小写，避免跨平台"幽灵异样"。

库表的层次：别把"库"和"表"混为一谈

你已经知道"服务器 → 库 → 表"是三层。这里反复出现的一个低级错误是：把表建错地方、或把库当表用。比如表属于某个库，查询时要么先 use 对库，要么用 库名.表名。create database 建的是"库"，create table 建的是"表"，两个命令的对象不同，别串。

SQL 分类：DDL / DML / DQL / DCL

现在，我们把 MySQL 里"说什么话"这件事规范化。SQL（Structured Query Language，结构化查询语言）是关系型数据库通用的"对话语言"，无论是 MySQL、Oracle 还是 PostgreSQL，核心 SQL 语法大致都相通。按作用，SQL 被分成四大类：

DDL —— 数据定义语言（Data Definition Language）

DDL 用来维护"存储数据的结构"，也就是建库、建表、删表、改结构这一类"动框架不动数据"的操作。代表指令：

  • create：创建数据库/表（create database、create table）
  • drop：删除数据库/表（drop table student; 直接连结构带数据一起删，很危险）
  • alter：修改表结构（如 alter table student add column age int; 给表加一列）

理解 DDL：它管的是"集装箱长什么样"。

DML —— 数据操纵语言（Data Manipulation Language）

DML 用来对"表中的数据"进行操作，也就是增删改"数据"本身。代表指令：

  • insert：插入一行数据（insert into ... values ...）
  • delete：删除数据（delete from student where id=1; 删掉 id 为 1 的那一行）
  • update：更新数据（update student set gender='女' where name='张三'; 把张三的性别改成女）

理解 DML：它管的是"集装箱里装什么货"。

DQL —— 数据查询语言（Data Query Language)

DQL 其实是 DML 中单独分出来的一块，专管"查询"。代表指令只有一句话：

  • select：查询数据（select * from student; 查全部，select name from student; 只查 name 列）

为什么要把 select 单独拎出来？因为查询在真实业务里出现频率最高、语法最复杂（多表连接、聚合、排序、分组都归它管），所以单独立类，方便深入。

DCL —— 数据控制语言（Data Control Language）

DCL 主要管两件事：权限管理和事务控制。代表指令：

  • grant：授予权限（grant select on helloworld.* to 'someuser'; 给某个用户授予对 helloworld 库查的权限）
  • revoke：回收权限
  • commit：提交事务（确认事务的修改生效）

需要说明的是，commit 其实更准确地属于"事务控制语言"（TCL，Transaction Control Language），但很多入门教材仍然把它划进 DCL。你能分清"权限用 grant/revoke、事务用 commit"这个实际用途就够了，具体术语各家归类略有差异不必死磕。

这四个分类建议背下来，它是你之后读任何 SQL 时的"类型雷达"：

SQL 分类全称管什么代表指令
DDLData Definition Language数据定义，维护结构create、drop、alter
DMLData Manipulation Language数据操纵，增删改数据insert、delete、update
DQLData Query Language数据查询（DML 的分支）select
DCLData Control Language数据控制：权限与事务grant、revoke、commit

思考题 6：下面这几条分别是哪一类 SQL？判断依据是什么？

  • create database shop;
  • select * from shop.order;
  • delete from shop.order where id=5;

答案与详解：

  • create 在"建库/建表、动结构"，属于 DDL（数据定义语言）。
  • select 是查询，属于 DQL（数据查询语言）。
  • delete 是删数据（不是删表），属于 DML（数据操纵语言）。 判断的关键是"动了什么"：动结构 → DDL；增删改数据 → DML；查数据 → DQL；权限事务 → DCL。

MySQL 的架构

最后简单聊聊 MySQL 的整体定位。MySQL 是一个可移植的数据库，几乎能在当前所有的操作系统上运行，如 Unix/Linux、Windows、Mac 和 Solaris。各种系统在底层实现上各有不同，但 MySQL 基本能保证在各平台上物理体系结构一致——意思是你在 Windows 上学的东西，搬到 Linux 上绝大多数概念、命令、SQL 都通用。

MySQL 在架构上还有一个非常鲜明的特点，那就是它的插件式存储引擎。这句话的意思是：MySQL 把"底层数据怎么存、怎么索引、怎么更新"这部分设计成可插拔的模块，你可以针对每张表选用不同的存储引擎来应对不同需求。这正是下一节的主角。

存储引擎：InnoDB 与 MyISAM 怎么选

存储引擎（Storage Engine）的定义，教材里给得就很准：它是"数据库管理系统如何存储数据、如何为存储的数据建立索引，以及如何更新、查询数据等技术"的实现方法。MySQL 的核心是插件式存储引擎，支持多种存储引擎，所以不同表甚至可以用不同引擎。

要知道你的 MySQL 支持哪些引擎，运行这一句：

-- 查看当前 MySQL 支持的所有存储引擎
show engines;
-- 会返回一张表，列里有 Engine、Support、Comment、Transactions、XA、Savepoints 等
-- Support 列的值是 DEFAULT 的那个，就是当前版本默认使用的引擎

在这张结果表里，你会看到 InnoDB 的 Support 列是 DEFAULT——因为从 MySQL 5.5 起，InnoDB 就是默认存储引擎（5.5 之前默认是 MyISAM）。此外还会看到 MyISAM、MEMORY、CSV、ARCHIVE 等。

在众多引擎中，最需要你重视的对比是 InnoDB 和 MyISAM：

对比维度InnoDB（现代默认）MyISAM（老牌）
事务（ACID）支持不支持
锁粒度行级锁，并发好表级锁，写时会锁整张表
外键约束支持不支持
崩溃恢复能自动恢复（redo/undo log）无日志，损坏可能丢数据
索引结构聚簇索引（主键即数据）非聚簇索引（数据与索引分离）
全文索引MySQL 5.6 起支持原生支持
适用场景业务数据、高并发、需要事务只读/历史归档、读多写少

简单记：InnoDB 是"银行柜台"——安全、可回滚、支持事务和行锁，适合业务；MyISAM 是"公告栏"——贴得快、读得快，但没有事务和行锁，只适合只读或历史归档。 所以除非有明确理由，现代项目一律建议用默认的 InnoDB。

以上存储引擎的核心事实（InnoDB 自 MySQL 5.5 起成为默认、支持事务与行级锁与外键、崩溃可自动恢复；MyISAM 不支持事务是表级锁、数据与索引分离、适合只读场景）经多方资料核对无误，可放心记忆。

思考题 7：一个"用户订单表"，一个"历史日志归档表"，分别该选什么存储引擎？为什么？

答案与详解：

  • 订单表用 InnoDB。因为订单涉及金额、状态变更，需要事务保证"扣钱和加钱要么一起成功要么一起回滚"，也需要行级锁来扛高并发下多个用户同时下单，还要崩溃自动恢复来兜底。这些都只有 InnoDB 能做。
  • 历史日志归档表用 MyISAM（或 InnoDB 也可，视需求）。这类表基本只写一次、只读，几乎没有并发写和事务需求，MyISAM 读快、结构简单、占用小，正好够用。 一句话：要事务、要并发、要安全就 InnoDB；纯只读归档才考虑 MyISAM。

到这里，MySQL 的"地基"就打完了。我们从"为什么不能只用文件"讲起，理清了数据库（DB）和数据管理系统（DBMS）的区别；认识了 SQL Server、Oracle、MySQL、PostgreSQL、SQLite、H2 这几大主流选手各自的长短；把"服务器—库—表—行/列"的三层结构刻进了脑子里；学会了用 mysql -h -P -u -p 连上一台服务器，亲手跑通"建库、用库、建表、插数、查数"这条最小闭环；还记住了 SQL 的四大分类——DDL 动结构、DML 增删改数据、DQL 查数据、DCL 管权限与事务；最后认识了 MySQL 插件式存储引擎，以及为什么现代默认都选 InnoDB。

你还避开了一批新手必踩的坑：分号是语句的结束符、库名表名在 Windows 和 Linux 上大小写敏感性不同（建议全小写保持跨平台一致）、库和表是两层别搞混。这些地基虽然"平"，但正是它们决定了你后面写全部 SQL 时手稳不稳。

下一篇文章，我们会拿这条最小闭环继续往下挖：更细致地看 create table 的列类型与约束（主键、非空、唯一）、select 的各种查询姿势、以及 DML 的增删改如何配合条件把数据玩转。把表结构这层打牢，你离"设计出别人夸的表"就不远了。准备好了吗？我们接着往下走。