数据库物理数据模型那些事儿，存储技能想熟练掌握得先懂它

综合自多本数据库系统概论类书籍、资深DBA社区经验分享以及软件研发技术博客中关于数据库底层存储的讨论）

数据库物理数据模型那些事儿,存储技能想熟练掌握得先懂它

很多人学数据库,会写复杂的SQL，知道怎么设计表之间的关系（这叫逻辑模型），但一碰到数据库反应慢、存储空间暴涨或者怎么选主键这类实际问题就头疼，这多半是因为不太清楚数据在硬盘上到底是怎么“住”下来的——这就是数据库物理数据模型要讲的事儿，你可以把它想象成房子的建筑设计图（逻辑模型）和实际施工时用的水电管线、承重结构图（物理模型）的区别，图画得再漂亮，管线铺得不合理，住起来照样麻烦不断。

物理数据模型具体关心些什么呢？它不管表叫“表”，它更关心的是“这个表的数据是怎么一堆一堆放在硬盘上的”，这就引出了第一个核心概念：表空间和数据文件。（来源：《数据库系统概念》等教材基础章节）数据库不是你建个表就直接往电脑硬盘上乱写的，它会先划出一些“地盘”，这些地盘叫表空间，每个表空间实际上对应着一个或多个实实在在的操作系统文件（数据文件），你可以把经常访问的热点表放在读写速度快的固态硬盘（SSD）对应的表空间里，把一些存档用的老数据放在速度慢但便宜的大容量机械硬盘对应的表空间里，理解了这个，你就明白了数据库的存储首先是有组织、分区域的，不是一锅粥。

光有地盘还不行,数据在里面怎么摆放才容易找？这就涉及到页（Page）和区（Extent） 的概念。（来源：Oracle、SQL Server、MySQL InnoDB等主流数据库的官方文档架构说明）硬盘读写数据最小单位是扇区，但数据库管理数据有个更大的基本单位，叫“页”（通常是4K、8K、16K大小），你可以把一页想象成一本练习簿的一页纸，表里的每一行数据，最终都会被塞进某一页里，数据库读写数据，基本上都是以“页”为单位来操作的，哪怕你只改一行数据，它也很可能把整页数据从硬盘读到内存，改完再写回去，而“区”呢，是连续的一系列页的集合，是数据库分配存储空间的基本单位，就像买作业本，你不是一页一页买，而是一本一本地买（一个区包含多个连续的页），了解页和区，你就能理解为什么有时候你只存一点数据，但数据库占用的硬盘空间却比实际数据大不少，因为它是按“区”这个整块来分配空间的。

数据放进页里了,怎么才能快速找到我想要的那一行？这就引出了索引这个最重要的物理结构。（来源：几乎所有数据库性能优化相关的书籍和文章，如《高性能MySQL》）索引就像是教科书最后的目录，没有索引，数据库要找你想要的数据，就得从第一页开始一页一页地翻，这叫全表扫描，速度极慢，而索引是一种单独的数据结构，它通过某种算法（最常用的是B+树）保存了数据表中某一列或几列的值，以及这些值对应数据行的“门牌号”（即行在数据文件中的物理位置），当你用索引列作为查询条件时，数据库会先去查这个“目录”（索引），快速找到门牌号，然后直接去对应的页里把数据拿出来，效率极高，但索引不是免费的，它就像书的目录也要占页码一样，索引本身也要占用额外的存储空间，每当你增删改数据时，数据库不仅要改数据本身，还得去更新相关的索引，这会带来额外的开销。“索引不是越多越好”这个常识，其根本原因就在于物理层面的这种额外成本。

除了索引,物理模型还决定了数据在页内是怎么排列的。（来源：数据库内核解析类技术文章）一行数据里各个字段是怎么存储的？有没有为了快速定位而预留的空间？当一页放不下超长的文本或二进制数据时怎么办？（这时候会有行溢出机制，把大数据存到别的页，本页只留个指针），还有，当数据被删除后，页里空出来的地方是立刻回收再利用，还是标记一下等以后再说？（这涉及到页内空间管理）这些细节都直接影响着存储空间的利用效率和读写速度。

物理模型还必须考虑事务是怎么保证数据安全的。（来源：数据库事务处理相关经典文献，如Jim Gray的著作）你转账操作，钱从A账户扣了，还没加到B账户上，这时候数据库崩溃了怎么办？物理模型通过日志文件（Redo Log, Undo Log） 来解决这个问题，redo日志记录的是“你准备怎么改数据”，undo日志记录的是“你改数据前的样子”，任何数据变更，都会先详细地写到日志文件里，然后才慢慢地写回数据文件，这样即使中途断电，重启后数据库也能根据日志把没完成的事务继续做完（redo），或者把半截子事务撤销掉（undo），从而保证数据不会错乱，日志文件的写入方式（比如顺序写）通常比随机写数据文件要快得多，这种设计巧妙地平衡了性能和可靠性。

所以说,想把数据库存储技能玩转，只停留在SQL层面是远远不够的，你得心里有张图：数据是如何被划分到不同的表空间和文件里，如何被切分成页和区来管理，如何通过索引这把“双刃剑”来加速访问，以及在页内部和整个系统层面，有哪些机制在保障数据高效、安全地存取，懂了这些“物理模型那些事儿”，你再面对SQL调优、存储规划、故障排查时，思路就会清晰很多，因为你知道了背后的“所以然”。