数据库里到底怎么存取数据，方法和原理其实没那么简单讲清楚

要讲清楚数据库里怎么存取数据，确实没法用一两句话说清，因为它不是一个动作，而是一整套环环相扣、精心设计的系统工程，我们平时感觉不到它的复杂，比如在网站上点一下“购买”，订单就存好了，这恰恰是数据库系统成功的地方——它把惊人的复杂性隐藏在了简单的接口后面，我们可以把它想象成一个超大型、超高效、且绝对不允许丢件的超级仓库,存取数据就是在这个仓库里存东西和找东西。

数据是怎么“存”进去的？这远不止是“写进硬盘”那么简单。

当你点击“提交”按钮时，你的数据（比如一条新注册的用户信息）首先到达的是数据库的“前台”——也就是数据库的服务进程，这个前台不会立刻就把数据扔进后面巨大的仓库（硬盘）里，因为硬盘的物理写入速度相比内存慢成千上万倍，如果每来一个数据就直接写硬盘,系统会慢得无法忍受。

数据库设计了一个“缓冲池”（Buffer Pool），你可以把它理解为仓库门口一个超级大的临时中转区，这个区域是设在速度极快的内存里的，数据首先会被放在这个中转区里，数据库会以一种非常严谨的格式把这条记录“打包”，这个格式只有数据库自己能看懂，里面包含了数据本身、记录的长度、以及其他管理信息，这个步骤确保了数据在系统内部可以被高效地处理和识别。（参考来源：数据库基本原理中的“缓冲池”与“日志先行”机制）

但这里有个致命问题：内存是带电工作的，一旦突然断电，中转区里的所有数据都会瞬间消失，如果数据只是放在中转区，还没写入硬盘，用户以为注册成功了，结果数据丢了，这是绝对不允许的,怎么办？

数据库用一个非常巧妙的“写日志”（Write-Ahead Logging, WAL）方法解决了这个问题，在把数据的变化真正写入到仓库的正式货架（数据文件）之前，数据库会先拿出一本“流水账笔记本”（重做日志文件），用最快的速度、按顺序写下今天要做的一件事：“下午2点01分，在用户表插入一条ID为1001的记录，姓名张三……”，这个写流水账的动作，是必须立刻、马上强制写入到硬盘上的日志文件里的，因为日志文件是顺序追加写的,速度比在数据文件里随机找位置写要快得多。

一旦这笔“流水账”稳稳地落在了硬盘上，数据库就可以放心地告诉应用程序“操作成功”了，因为即使此时断电，内存中转区的数据丢了也没关系，重启之后，数据库可以拿出那本“流水账笔记本”，把上面记录了的、但还没正式入库的操作重新做一遍，从而保证数据不会丢失，这个“先记流水账，再改正式账”的原则，是数据库可靠性的基石。（参考来源：事务的ACID特性与WAL原理）

数据库会在合适的时机（比如中转区快满了，或者系统空闲时），再将中转区里那些已经被记录在“流水账”里的数据，真正地、持久化地写入到仓库的正式货架——也就是硬盘上的数据文件中，这个过程可能涉及到在庞大的数据文件中寻找空闲的页面来存放新数据，管理文件空间,这些都是存储引擎的核心工作。

数据又是怎么“取”出来的？这更体现设计的智慧。

当你要查询“用户张三的信息”时，数据库面临的挑战是：仓库（硬盘）太大了，数据存放的物理位置和逻辑顺序（比如按ID排序）可能并不一致，如果每次都像无头苍蝇一样全仓库扫描，从上亿条记录里一条一条地找,那将是灾难性的。

数据库引入了“索引”（Index）的概念，索引就像图书馆的目录卡片或者一本书的目录，你不需要翻遍整本书才能找到某一章，通过目录就能快速定位到页码，数据库索引也是类似的原理，它是一种独立于主数据之外的特殊数据结构，它只保存你经常用来查询的字段（比如用户ID、用户名）和对应数据记录在硬盘上的物理地址。

常见的索引结构是B+树，这种结构就像一个多层的、平衡的树状目录，从根节点开始，经过几层中间节点的快速比较，就能迅速定位到叶子节点，叶子节点里就存放着指向真实数据行的指针，由于这棵“树”的层级通常很浅（可能3-4层就能管理数亿条记录），并且索引本身也会被放在高速缓冲池里，所以通过索引查找数据，可能只需要几次极快的磁盘I/O（甚至完全在内存中完成），就能从海量数据中精准定位，效率极高。（参考来源：数据库索引技术，特别是B树与B+树结构）

但索引也不是免费的午餐，它虽然极大地加快了查询速度，但每当新增、删除或修改数据时，数据库不仅要改动主数据，还需要维护所有相关的索引，以保证索引的正确性，这就会降低数据写入的速度，在一个系统中建多少索引、建哪些字段的索引，需要根据实际的读写比例进行权衡，这是一种典型的“以空间换时间”的策略。

数据库的存取远非简单的“写盘”和“读盘”，它涉及到内存与硬盘的多级速度缓冲、为保证可靠性而设计的日志先行机制、高效的空间管理以及为快速查询而建立的复杂索引结构，这些组件协同工作，共同构成了一个既可靠又高性能的数据存取系统，正是这些底层复杂的原理和方法,才支撑起了我们眼前这个瞬息万变的数据世界。