数据库基础

你手机里的数据通讯录、微信聊天记录、库基淘宝订单，数据背后都躺着一个数据库。库基它不声不响，数据但一旦挂了，库基整个公司可能就瘫了。数据

我见过一个创业团队，库基早期用Excel管理用户数据，数据几个人同时改一个文件，库基版本乱成一锅粥。数据后来换了MySQL，库基才算走上正轨。数据数据库解决的库基核心问题就一个：让多个程序、多个人，数据能同时可靠地读写同一份数据。

表、行、列——最基础的三件事

数据库里最核心的结构是表。你可以把它想象成一张Excel表格，每一列定义了数据类型，比如“姓名”是文本，“年龄”是整数，“注册时间”是日期。每一行则是一条完整记录。

但数据库比Excel严格得多。你往“年龄”列里塞一个“abc”，数据库直接报错拒绝。这种约束看起来麻烦，实际上救了无数程序员——数据质量从源头就被卡住了。

拿一个订单表举例：

CREATE TABLE orders ( id INT PRIMARY KEY, user_id INT, amount DECIMAL(10,2), created_at DATETIME );

PRIMARY KEY是主键，保证每一行都能被唯一找到。没有主键的表，就像一本没有页码的书，翻到哪算哪。

SQL：跟数据库说话的方式

写SQL本质上是在描述“我想要什么”，而不是“怎么去拿”。比如查某个用户最近三笔订单：

SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 3;

数据库引擎自己决定走哪条路——先扫全表还是先走索引，用哪个算法排序。你只负责说清楚需求。这种声明式的思路，跟写Python或Java完全不同。

我刚学SQL时觉得它像英语句子，后来发现更像数学集合运算。JOIN是把两个集合按条件拼在一起，GROUP BY是分组统计。想通了这层，很多查询写起来就顺了。

索引：快与慢的分界线

一张百万行的表，没索引时查一条记录可能要几秒。加了索引，毫秒级返回。

原理不复杂。没索引就像翻字典一页页找字，有索引就像直接查部首目录。B+树是数据库最常用的索引结构，它把数据按顺序组织成多层节点，每次查找都能排除掉绝大部分数据。

但索引不是越多越好。每次插入、更新、删除，索引都要跟着调整。一个表上建七八个索引，写入性能会明显下降。我见过有人给每个列都加索引，结果插入一条数据要等半秒。索引是拿写入换读取，这笔账得算清楚。

事务：要么全成，要么全不成

转账是最经典的例子。A账户扣100块，B账户加100块，这两步必须一起成功或一起失败。否则钱就凭空消失或出现了。

事务的ACID特性里，原子性管的就是这个。数据库保证一组操作要么全部生效，要么全部回滚。你不需要在代码里写一堆补偿逻辑，数据库帮你兜底。

不过事务也有代价。长事务会锁住资源，影响其他请求。线上系统里，一个跑了几分钟还没提交的事务，往往就是故障的源头。

选型这件事，别跟风

MySQL、PostgreSQL、MongoDB、Redis，各有各的适用场景。关系型数据库适合结构化数据和复杂查询，文档数据库适合字段灵活多变的场景，Redis适合高速缓存。

我个人的判断标准很简单：数据需不需要强一致性？需不需要复杂关联查询？如果两个都是“是”，老老实实用关系型数据库。别因为MongoDB看起来时髦就硬上，后期数据一致性问题会让你头疼很久。

数据库这门手艺，入门容易精通难。会写几条SQL不难，难的是理解它内部怎么执行、怎么优化、怎么在故障时恢复。这些知识，往往在系统出问题的时候才显得格外值钱。

很赞哦!（5）