Mr.括号1. 为什么非要搞出个“数据库”不可：从Excel地狱说起
先讲个我早年经历过的真实场景。有个做电商运营的朋友，店铺从每天几十单做到上千单，一直用Excel管订单。结果某天下午，两个客服同时改一份订单表：一个在改收货地址，另一个在标记已发货，保存的时候后保存的人把先保存的覆盖了。客户投诉说地址改错了，货发到老地址去了。朋友折腾到半夜，最后只能在群里发了个公告：以后谁改完表格，都要在文件名后面加上自己的名字和时间。
这种办法当然不靠谱。第二天有人忘了加后缀，直接覆盖了全表。当时他来找我，问我怎么办。我跟他说：你的问题不在于表格用得好不好，而在于你已经到了该用数据库的时候了。数据库本质上解决的就是Excel这种单文件方案撑不住的那几件事。
第一个是并发控制。当多个人同时读、同时写同一份数据时，数据库会用锁机制、MVCC（多版本并发控制）来保证不丢数据。Excel的“后保存者覆盖先保存者”在数据库术语里叫“丢失更新”，数据库有成熟的机制来避免。
第二个是数据一致性。比如下单扣库存这个动作，订单要加一条，库存要减一条，两个操作必须都成功或者都失败。如果在Excel里手动操作，很可能出现订单建了但库存没扣的情况。数据库事务（Transaction）就干这个事。
第三个是崩溃恢复。Excel最怕的是什么？文件损坏打不开。数据库有自己的日志系统，哪怕机器断电崩溃，重启后也能通过日志把数据恢复到崩溃前的一致状态。
第四个是查询能力。几千行数据的时候Excel还能筛筛选选，到几十万行的时候，Excel基本就卡死了。数据库用索引、优化器来查询，百万行级别也是毫秒级响应。
第五个是安全与权限控制。数据库可以精确控制某个用户只能看某些表的某些列，Excel从机制上做不到这种细粒度。
所以，数据库系统概念这门课，拆开来看，核心就是在解决这几个问题：怎么存、怎么查、怎么改、怎么保证不崩、怎么保证多个人同时用还不出乱子。明白了这一点，后续所有概念都会围绕这几条主线展开。
注意：搜索引擎里有大量关于“数据库死锁”“数据库并发锁”“数据库增删改查”的搜索热词，本质都是这几个核心问题的延伸。先把问题的维度建立起来，后面学任何具体技术点都不容易迷路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库系统到底由什么组成：存储、引擎与那些看不见的日志
咱们平时说“装个MySQL”“装个Oracle”，感觉是个一体的软件。但实际上数据库系统是分层的，这一层一层拆开来看，概念就清楚多了。
2.1 存储层：数据和元数据怎么落盘
存储层解决的核心问题是：数据到底怎么放在磁盘上。传统数据库最朴素的做法是文件组织，表数据按行存储在一个个数据页（Page）里，一个数据页通常是4KB到16KB。页是数据库和磁盘打交道的最小单位，读一页和读一个字段的开销差不了太多，所以数据库宁愿一次多读点，也要尽量减少IO次数。
存储层里还得区分数据（Data）和元数据（Metadata）。数据是咱们存的业务内容，元数据是描述数据的数据——比如这个表有哪些字段、字段是什么类型、谁建的表、索引怎么组织的。MySQL的information_schema库就是干这个的，里面存的全是元数据。很多做数据库运维的人天天跟元数据打交道，就是这个道理。
2.2 存储引擎：决定了一个数据库的“脾气”
存储引擎是数据库中最核心的可插拔部件，它决定了数据怎么存、怎么取、支不支持事务、支不支持行锁还是表锁。MySQL最常用的InnoDB引擎支持事务、支持行级锁、支持崩溃恢复；而老旧的MyISAM引擎速度在某些场景下不错，但不支持事务，一崩就可能丢表。
打个比方：数据库是一个大餐厅，存储引擎是后厨。客人（应用）只需要跟服务员点菜（发SQL），完全不关心后厨用的是燃气灶还是电磁炉。换个后厨设备，不影响营业，只影响菜品的稳定性和出餐速度。
这个比喻可以延伸到面试里最常问的那类问题：“为什么事务要放在引擎层而不是Server层？”因为事务本质上是一种存储管理策略，它牵扯到日志的写入策略、锁的管理、数据页的回滚，这些是存储引擎的职责边界，不是语法解析器的职责边界。
2.3 日志系统：数据库崩溃后靠什么活过来
数据库里最容易被小白忽视但最值得花时间理解的部分，就是日志系统。关系数据库的日志主要分两类：重做日志（Redo Log） 和撤销日志（Undo Log）。
Redo Log解决“崩溃后已提交的数据不能丢”的问题。你执行一个UPDATE语句，数据库不会直接去改磁盘上的数据文件，而是先把这个修改记入内存缓冲区，并把修改操作顺序写入Redo Log。日志一旦写完，事务就算提交成功了。之后哪怕机器立刻断电，磁盘上的数据文件还是旧值，也没关系——数据库重启后，会根据Redo Log把已经提交的事务重新做一遍，让数据文件恢复到最新状态。
Undo Log解决的是“事务回滚时怎么恢复旧值”的问题。它记录了修改之前的旧值，执行ROLLBACK时，通过Undo Log把数据恢复到修改前。另一个重要用途是配合实现MVCC多版本读，让你在一个事务里反复读同一行数据时，始终看到的是事务开始时的那个版本。这也是为什么高并发系统里“读写不互斥”——读的其实是旧版本，不必等写操作完成。
经验之谈：很多新手会把Redo Log和Binlog搞混。Redo Log是引擎层的物理日志，记录的是“数据页怎么改”；Binlog是Server层的逻辑日志，记录的是“这个SQL执行了什么”。两者用途不同，主从复制用的是Binlog，崩溃恢复用的是Redo Log。面试时能把这个区分说清楚，已经可以秒掉一大半候选人了。
3. 为什么现代数据库都长着一张“表”脸：关系模型是怎么统治世界的
你在热搜词里会看到“数据库sql”“查询数据库”“mysql数据库修改结构”“数据库增删改查”——这些全部建立在同一个底层模型上：关系模型。理解关系模型，基本就理解了为什么现代数据库SQL长得差不多、表结构设计要遵守那些规则。
3.1 关系模型的三件套：表、行、列
关系模型的发明人是IBM的科德（E.F.Codd），1970年提出。核心思想极其朴素：数据用二维表来表示，一张表（Table）就是一个关系，表里的每一行（Row）是一个元组，每一列（Column）是一个属性。
为什么这个模型能统治数据库世界50多年？因为它把数据的逻辑结构和物理存储彻底解耦了。用户眼里数据就是一张张表，怎么在磁盘上存，那是引擎的事。这样带来的好处是极其巨大的：你不需要懂磁盘、不懂索引结构也能用数据库。这正是“数据库系统概念”这门课为什么首先讲关系模型的原因。
3.2 主键与外键：表之间怎么产生联系
表不是孤立的，它们通过键关联起来。
主键（Primary Key）是表中能唯一标识一行记录的列或列组合。比如用户表里的用户ID，订单表里的订单号。主键有两个约束：非空且唯一。
外键（Foreign Key）是一个表中的列，引用另一个表的主键。比如订单表里的user_id，引用用户表的id，就是从用户表“继承”过来的外键。
外键是所有关系模型讨论的起点。为什么订单不能把用户的姓名、电话、地址直接复制一份存进来？因为一旦用户改了资料，所有历史订单里的旧信息都成了脏数据。正确的做法是只存user_id，要用姓名电话时通过JOIN关联用户表去查。这就是“规范化”的朴素思想。
3.3 范式：表结构设计的“规矩”
很多人在学习数据库时，被“范式”两个字劝退。其实范式没那么可怕，它是一套用来判断表结构设计合不合理的原则，核心就是：尽量避免数据冗余，保证数据更新的一致性。
第一范式（1NF）要求每个列都是原子的，不可再拆。比如“地址”列存了“北京市海淀区中关村大街1号”，如果再需要按城市统计，就应该拆成“省、市、区、详细地址”多列。
第二范式（2NF）要求表里的每一列都完全依赖于主键，而不是主键的一部分。典型反例是：(订单ID, 商品ID)作为联合主键，却把商品名称存在表里。商品名称只依赖商品ID，不依赖订单ID，这就会导致同一商品名存了无数遍。应该把商品信息拆到商品表里。
第三范式（3NF）要求列不依赖主键之外的列。比如用户表里有“部门ID”和“部门名称”，部门名称依赖的是部门ID而非用户ID。应该拆出部门表，用户表只留部门ID。
个人体会：实际项目中，一线开发者普遍不会严格追求BCNF或4NF，最多到第三范式。而且到了互联网高并发场景，经常反其道而行之，故意在表中冗余一些字段来减少JOIN，这叫“反范式设计”。但无论怎么反，都要有意识——你得知道自己正在违反哪条规范，以及为什么要违反，这跟不懂范式的乱设计完全是两码事。
3.4 SQL为什么那么“像英语”
SQL的成功，很大程度上归功于它长得像英语，声明式（Declarative）而非过程式（Procedural）。你只需要告诉数据库“你要什么”，而不用告诉它“怎么取”。
sql复制SELECT user_id, user_name
FROM users
WHERE register_date >= '2024-01-01'
ORDER BY register_date DESC
LIMIT 100;
这句SQL读出来就是“从users表里select这些列，where满足某条件，order by排序，limit取100条”。任何会英文的人都能大致看懂。但数据库内部是怎么执行的——走哪个索引、用什么JOIN算法、怎么排序——完全不用你操心，优化器会搞定。
这个特点让数据库的使用门槛降到极低，也是它能在各种行业普及的重要原因。你可以不懂B+树、不懂事务原理，照样能写SQL干活。但如果你未来想解决慢查询、死锁这类问题，就还是得回到底层机制里去。
4. 选型不是选最火的，是选最适合的：关系数据库与非关系型数据库的差异
热搜词里你几乎能看到所有主流数据库的名字：mysql、oracle、sqlite、达梦、人大金仓、doris、向量数据库……一个新人很容易被搞晕：我到底该学哪个？选哪个？
答案是：先别急着选，先理解数据库的分类图谱。分类清楚了，选型就变成了一道问答题。
4.1 关系型数据库（SQL数据库）
这类数据库基于关系模型，用SQL操作，强调事务ACID特性。代表产品：
- MySQL：开源、社区活跃、生态庞大。中小型项目的绝对主力，互联网行业事实标准。
- PostgreSQL：功能更丰富，支持更复杂的数据类型和高级索引，在GIS、金融等对数据完整性要求高的场景中很强。
- Oracle：老牌商业数据库，功能强大，稳定性和性能都非常出色，常见于大型企业传统IT系统，但License费用贵。
- SQL Server：微软家的产品，和.NET技术栈深度集成，企业级Windows环境里很有统治力。
- SQLite：嵌入式数据库，整个数据库就是一个文件，无需独立服务，移动端和本地工具的绝配。
- 达梦、人大金仓：国产数据库的典型代表，目前在很多政企、金融国产化替代场景中大量使用，语法和用法与Oracle/MySQL高度兼容。
4.2 非关系型数据库（NoSQL）
NoSQL不是一个具体产品，而是一类数据库的总称。它牺牲了部分事务和关联查询的能力，换取的是横向扩展能力或特定的数据模型匹配。
- 键值存储（Redis）：数据以Key-Value形式存在内存中，极快，适合缓存、计数器、Session管理。
- 文档数据库（MongoDB）：存JSON/BSON格式的文档，结构灵活，适合内容管理、用户资料、日志类场景。
- 列族数据库（HBase、Cassandra）：按列族存储，适合海量数据的大规模分布式读写。
- 图数据库（Neo4j）：专门处理实体和关系，适合社交网络、推荐系统、风控反欺诈。
- 向量数据库（Milvus、Pinecone、Weaviate）：这是近两年的热门方向，围绕AI嵌入向量做相似度检索，支撑RAG（检索增强生成）和语义搜索场景。
4.3 实际的选型逻辑是什么
我在带团队时总结了一套很实用的决策流程：
- 数据是否需要强事务保证？ 涉及钱、库存、订单这些，优先考虑关系型数据库，别拿NoSQL硬扛。
- 数据规模是否会增长到单机扛不住的量级？ 如果刚开始不确定，先用MySQL单实例甚至SQLite起步，做大了再分库分表或者换分布式数据库。大多数项目的瓶颈远没到需要分布式的地步，过早引入分布式复杂度是灾难。
- 数据模型是否天然适合某种NoSQL？ 如果业务数据是一棵巨大的树或图（比如组织架构、社交关系），用图数据库会让查询简单一个数量级。
- 团队技术栈是否匹配？ 选一个团队熟的产品，比选一个“技术最好”但没人会用的产品划算得多。
热词里有“快速开发一套带数据库的软件用什么开发环境最好”，我的答案是：先选数据库再选语言。业务逻辑复杂、事务要求高的用PostgreSQL或MySQL；中小型项目图省事用SQLite；已经确定用Java的那就Spring Boot + MySQL，Python那就FastAPI/Django + PostgreSQL。工具永远是为业务服务的，别让选型焦虑绑架了项目。
5. 从概念到建表：小白的第一张表该怎么画
概念讲再多，不动手永远是纸上谈兵。这一节咱们拿一个真实场景，走一遍从业务分析到建表完成的完整流程。
5.1 第一步：识别业务中的“实体”
假设咱们要做一个最简单的用户订单系统。动笔之前先想清楚：系统里有哪些核心对象？
业务对象跑不掉这样几类：
- 用户（User）：下单的人。
- 订单（Order）：一次购买行为。
- 商品（Product）：卖的东西。
- 订单明细（OrderItem）：一个订单可能包含多个商品，每个商品买几件、单价多少。
这四个实体就是第一版表结构设计的骨架。实体之间是什么关系？用户和订单是1对多：一个用户有多个订单；订单和商品是多对多：一个订单包含多个商品，一个商品出现在多个订单里。多对多关系必须拆成中间表，也就是订单明细表。这个中间表会同时带上订单的ID和商品的ID。
5.2 第二步：确定每张表的字段
给每个实体罗列属性时，一个实用原则是：先列出你当下能确定的，不要为了“完整”去设计用不到的字段。很多新手喜欢在表里加一堆预留字段，比如redundant_1、redundant_2，最后全部变成无人维护的死字段。数据库表结构的演进，应该靠后续ALTER TABLE去迭代，而不是一开始就做“伪完整”。
用户表核心字段：
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | BIGINT | PRIMARY KEY, AUTO_INCREMENT | 用户唯一ID |
| username | VARCHAR(50) | NOT NULL, UNIQUE | 用户名 |
| password_hash | VARCHAR(255) | NOT NULL | 密码哈希 |
| VARCHAR(100) | UNIQUE | 邮箱 | |
| phone | VARCHAR(20) | 可空 | 手机号 |
| created_at | DATETIME | NOT NULL | 注册时间 |
订单表核心字段：
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | BIGINT | PRIMARY KEY, AUTO_INCREMENT | 订单ID |
| user_id | BIGINT | NOT NULL, FOREIGN KEY REFERENCES users(id) | 下单用户 |
| status | TINYINT | NOT NULL, DEFAULT 0 | 订单状态：0待支付 1已支付 2已发货 |
| total_amount | DECIMAL(10,2) | NOT NULL | 订单总金额 |
| created_at | DATETIME | NOT NULL | 下单时间 |
订单明细表核心字段：
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | BIGINT | PRIMARY KEY, AUTO_INCREMENT | 明细ID |
| order_id | BIGINT | NOT NULL, FOREIGN KEY REFERENCES orders(id) | 所属订单 |
| product_id | BIGINT | NOT NULL, FOREIGN KEY REFERENCES products(id) | 商品 |
| quantity | INT | NOT NULL | 购买数量 |
| price | DECIMAL(10,2) | NOT NULL | 购买时的单价快照 |
注意里面这个单价快照。为什么不直接去JOIN商品表拿现价？因为下单之后商品价格可能调整。如果订单明细只存product_id，将来打报表时价格全变了，财务就对不上了。在明细表里冗余一份价格快照，是典型的“反范式换可靠性”，而且这种冗余是合理且必要的。
5.3 第三步：建表SQL实操
字段设计完，SQL写起来就很快了。以MySQL为例：
sql复制CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
email VARCHAR(100) UNIQUE,
phone VARCHAR(20),
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE products (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
product_name VARCHAR(200) NOT NULL,
price DECIMAL(10,2) NOT NULL,
stock INT NOT NULL DEFAULT 0,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
status TINYINT NOT NULL DEFAULT 0,
total_amount DECIMAL(10,2) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE order_items (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL,
product_id BIGINT NOT NULL,
quantity INT NOT NULL,
price DECIMAL(10,2) NOT NULL,
CONSTRAINT fk_items_order FOREIGN KEY (order_id) REFERENCES orders(id),
CONSTRAINT fk_items_product FOREIGN KEY (product_id) REFERENCES products(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意几个细节：
- 字符集用utf8mb4，而不是utf8。utf8在MySQL里最多存3字节，遇到emoji或者生僻字直接报错，utf8mb4是完整的4字节UTF-8。
- 自增主键用BIGINT而不是INT。INT最大大概21亿，订单量上来后很容易撞上限，用BIGINT是成本几乎为零的保险。
- 金额类型用DECIMAL而不是FLOAT。FLOAT是浮点数，0.1 + 0.2跑出来可能等于0.30000000000000004，钱算错是要出事的，DECIMAL是精确小数。
这段建表语句实际跑一遍，你就把“实体识别、字段设计、外键约束、数据类型”这些概念全部落到了实处。
提示：能正确设计出一张不违反第三范式的表，又能在必要处合理冗余，已经胜过很多工作两三年的开发了。表结构的功底都是在真实业务的反复打磨中练出来的。
6. 事务、并发与那些面试题背后的真相
做了几年数据库相关工作后你会发现，平时写CRUD根本碰不到什么技术深水区，真正让人头秃的全是这几个问题：数据同时对不上账了、线程卡死了、数据库CPU飙高了。这些事情背后的原理，都在事务和并发控制这两块。热搜词里“数据库死锁”“数据库并发锁”“数据库面试题”全扎堆在这里，不是没原因的。
6.1 事务的ACID到底是怎么实现的
事务有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
这四个特性不是凭空来的，每个都有对应的实现机制，我把它们串成一个故事讲。
你去银行转账，从A账户扣1000元，往B账户加1000元。第一步是原子性：这个操作要么全成功，要么全失败，不能出现扣了钱但没到账。原子性靠的是Undo Log，如果第二步失败，机制上会把第一步的修改“回滚”成没发生过。
第二步是持久性：一旦你看到“转账成功”的页面，即便此时机房断电重启，这笔转账也不能丢。持久性靠的是Redo Log，在事务提交前，修改操作已经被顺序写入磁盘日志，这跟数据文件是否落盘没有必然关系，日志在，数据就能重建。
第三步是隔离性：两个同时发生的转账，不能互相看到对方的中间状态。隔离性靠的是锁和MVCC。如果小明和小红同时给同一账户转钱，正确的结果是两笔都生效。如果隔离没做好，就可能出现两个事务都读到余额1000，各加500，最后余额变成了1500而不是2000，这就是丢失更新。
第四步是一致性，它跟前三者的关系是：只有原子性、隔离性、持久性都保证了，业务上定义的总量守恒之类的不变量才永远成立。一致性更准确地说，是业务逻辑和数据库机制共同作用的结果。数据库给你工具，你得用对。
6.2 并发控制：锁和隔离级别
并发控制最核心的无非两件事：锁和隔离级别。
MySQL InnoDB支持行级锁和表级锁。行锁粒度小并发高，但有死锁风险；表锁简单粗暴，并发一高就是灾难。具体用哪种锁，大多数时候不用你操心，事务自动给你加。真正需要你去思考的，是隔离级别的选择。
SQL标准定义了四个隔离级别：
- 读未提交：能读到别人没提交的数据，脏读（Dirty Read）风险。实际生产环境几乎没人用。
- 读已提交：只能读到别人提交后的数据，避免了脏读，但一个事务里两次同样的查询可能查到不同的结果，这叫不可重复读（Non-Repeatable Read）。
- 可重复读：MySQL的默认级别。事务开始后，重复读同一行永远是同样的值，靠MVCC快照实现。但依然可能产生幻读——查询一个范围内的记录时，其他事务插入了一行符合条件的记录，第二次查询多了一行。
- 串行化：事务之间完全排队，无并发问题，但性能堪忧。
我在实际项目里经常被问到“怎么选隔离级别”，我的建议是：没有特殊理由就用数据库默认级别，MySQL默认可重复读，PostgreSQL默认读已提交。非要改之前，先掂量清楚业务能不能接受对应的并发异常。绝大多数业务，默认级别完全够用，强行上串行化并不会有“更安全”的额外好处，只会白白损失吞吐量。
6.3 死锁是怎么发生的，怎么处理
死锁是并发事务的经典难题。用一个经典例子说明：事务A先锁了user表的一行，又去锁order表的一行；事务B先锁了order表的一行，又去锁user表的那一行。两个事务互相等待对方释放锁，谁也不肯让，就成了死锁。
数据库不是完全没有办法。InnoDB有死锁检测机制，发现死锁后，会强制回滚其中一个事务，另一个得以继续。所以遇到死锁的第一原则是：死锁错误发生时，业务端要捕获错误并重试整个事务，而不是直接崩溃退出。这一条在几乎所有语言的数据访问层都有标准写法。
另一种策略是固定加锁顺序。如果只允许事务严格按照“先user后order”的顺序加锁，就不会出现循环等待。很多高并发系统的代码规范里都会强制要求这种排序，从根上掐死死锁。
还有一条实际经验：事务尽量短小精悍，不要在事务里执行远程HTTP调用或者大量的复杂计算。锁的持有时间越长，碰撞的概率越高，死锁和锁等待的概率都成倍上涨。我看到过不少线上事故，就是因为在事务里调外部接口超时，导致数据库连接池被占满，整库雪崩。事务最小化，是并发编程里一条永远适用的铁律。
6.4 回到面试题：这些知识怎么串起来用
热词里有人搜“数据库面试题”，很多经典题其实都是这一章概念的应用题。比如：
- “MySQL的默认隔离级别是什么？为什么？” 答案是可重复读，因为MySQL的Binlog在statement格式下需要可重复读才能保证主从数据一致。
- “什么是MVCC？” 本质就是通过Undo Log构造历史版本链，让读操作不加锁也能读到一致快照。
- “什么时候会用到表锁？” 整表加字段、加索引时，DDL会拿表锁；InnoDB在并发极低或某些特殊语句下也可能退化到表锁。
这些题看起来多，但只要你把事务的原理、锁的机制、日志的用途搞清楚了，考来考去都逃不出这摊事。
7. 实用的学习路线：从概念到能干活还要补哪些课
如果这篇文章的目标是“数据库系统概念”的入门，那么最后一个实际问题是：读完这些概念之后，下一步该干嘛？
我给一条比较务实的路：
- 第一步：把所有SQL基础操作写熟。增删改查、WHERE过滤、ORDER BY排序、LIMIT分页、GROUP BY分组、JOIN多表连接。找一套练习数据，把五十道以上的SQL练习题刷完，速度和准确率都比看书重要。
- 第二步：把一个数据库真正用起来。推荐从MySQL或PostgreSQL开始。自己定义一套业务模型（比如文章系统的用户表、文章表、评论表、标签表），建库建表，写一些模拟数据，再写查询。卡住的时候去翻官方文档，比看二手资料快得多。
- 第三步：理解索引原理。这是从“会写SQL”到“SQL写得快”的分水岭。搞清楚B+树为什么适合范围查询、聚簇索引和非聚簇索引的区别、联合索引最左前缀原则。然后用EXPLAIN看执行计划，验证自己的索引设计是否有效。
- 第四步：学习事务和备份恢复。开启事务做插入和回滚实验，设置不同的隔离级别观察不同异常现象。再学会用mysqldump做逻辑备份、用binlog做增量恢复，这是运维的基本功。
- 第五步：根据工作方向选进阶路线。走开发方向就学ORM框架、连接池、分库分表；走DBA方向就学监控、性能调优、高可用架构。
至于阅读材料，经典教材依然是《数据库系统概念》原书，但我的建议是别把它当小说啃，而是当成字典查。先动手，遇到不懂的概念再回来看对应章节，效果比从头翻到尾好得多。
数据库这个东西，入门靠的是动手量，拔高靠的是原理吃的透不透。前50个小时的动手能把门外汉变成能用的人，再往后，区分技术天花板的，就看你对今天讲的这些概念——存储、索引、事务、并发——到底悟到了几分。