聊到数据库大多数人第一反应是SQL写法、索引设计、优化器行为。但真正跑过线上系统的人都明白一台数据库在压力下是稳如老狗还是彻底卡死胜负手往往不在SQL而在存储这一层。这段时间我把《数据库系统概念》第十章“存储和文件结构”重新过了一遍结合这几年做性能排查和容量规划踩过的坑整理成一份偏实战的笔记。这篇文章不讲虚的把存储介质、RAID、文件组织、缓冲管理这些概念全部落到“为什么会这样设计”和“线上遇到问题怎么判断”上。不管是正在学数据库原理的学生还是要处理慢查询和IO瓶颈的开发者这部分内容都能帮你少走弯路。1. 从存储介质看数据库的“快”与“慢”1.1 先理解存储层级教科书里给了一个很经典的存储层次寄存器、高速缓存、主存、闪存、磁盘、磁带。越往上速度越快、价格越贵、容量越小越往下则反过来。数据库系统之所以要把数据分层放置核心原因就两个成本和持久性。如果把所有数据都放内存性能当然好看但容量上不去价格也扛不住更关键的是内存断电就没。所以数据库设计的基本盘是内存用来放热数据和临时计算结果磁盘或闪存用来放全部持久化数据。这个分层思路贯穿了整个数据库体系结构连查询优化器都要考虑“数据在内存还是磁盘”来决定执行策略。实际工作里最常见的误区是把“内存命中率”看成唯一指标。其实存储介质本身的延迟差异才是根因。一次内存访问大约是几十纳秒级别一次SSD随机读是几十微秒而一次机械盘随机读往往是几毫秒。这几个数量级的差距决定了SQL能不能扛住高并发。1.2 磁盘访问时间拆开算机械硬盘的访问时间可以拆成三部分寻道时间、旋转延迟、传输时间。寻道是磁头移动到目标磁道旋转延迟是等待目标扇区转到磁头下面传输时间则是数据真正读出写入的时间。这里有个经常被忽略的公式旋转延迟大约是磁盘转半圈的时间。一块7200转的盘每分钟7200转也就是每秒120转转一圈需要8.33毫秒半圈就是4.17毫秒左右。再加上常见的4到10毫秒寻道时间单次随机IO的延迟通常在8到15毫秒之间。这时候就能算出单盘机械硬盘的随机IOPS大概是多少1000毫秒除以10毫秒差不多就是100次每秒。这就是为什么机械盘做随机小IO非常吃力。很多教材喜欢直接给一个“随机IO比顺序IO慢几个数量级”的结论但我觉得更值得记住的是这个计算过程。因为当你用iostat看到某块盘await到了15毫秒以上你能立刻意识到这块盘的随机访问已经逼近物理极限了而不是去怀疑数据库配错了参数。1.3 闪存和SSD改变了很多事情SSD普及后存储延迟大幅度下降但闪存有自己的一套物理特性不能简单当成“快一点的磁盘”来用。NAND闪存的最小读写单位是页常见4KB到16KB但擦除操作的最小单位是块一个块包含多个页。这意味着你要改写某个页里的数据往往要把整个块读出来、擦除、再写回去。这就是常说的写放大问题。频繁的小写入实际落盘的数据量可能远大于应用层写入的数据量时间一长会加速闪存磨损。数据库场景里最容易踩SSD这个坑的就是日志写入。很多数据库默认日志刷新策略是每次提交都fsync一次产生大量4KB甚至更小的写。机械盘时代这么做是为了保事务SSD时代如果不对日志做合并和分组提交写放大就会非常明显。所以现代数据库都在做group commit把多个事务的日志刷盘合并成一次这不仅是CPU优化更是对闪存寿命的保护。另外SSD的随机读能力非常强但随机写仍然比随机读慢尤其是消费级SSD在没有掉电保护的情况下突然断电可能导致缓存里的数据丢失。这也是为什么生产环境数据库盘通常要选择带掉电保护的存储哪怕多花点钱。注意判断存储健康度时不要只盯“磁盘利用率util”这个指标。SSD因为内部并发高util到100%不代表真的满了还要结合队列深度和实际延迟一起看。单纯看util做告警容易出现误判。2. RAID别让一块盘的故障拖垮数据库2.1 RAID级别与数据库场景RAID的核心目标就两个提升性能、增强可靠性。不同级别在容量利用率、IOPS、写放大之间做取舍。RAID 0把数据条带化到多块盘容量和性能都能提升但没有任何冗余一块盘坏了数据全没。数据库几乎不用RAID 0除非你明确在做临时库或者丢了无所谓的数据。RAID 1是镜像每份数据写两份可靠性好但容量利用率只有50%。RAID 5用分布式奇偶校验允许坏一块盘容量利用率高但每次写都要额外计算和写入奇偶校验信息写惩罚明显。RAID 6允许坏两块盘可靠性更高但写入代价更重重建也慢。RAID 10是镜像加条带先做RAID 1再做条带化。它既保留了镜像的高可靠性又能通过条带化提升并发读写性能写惩罚相对可控。数据库生产环境用得最多的就是RAID 10尤其是存放核心数据文件的场景。我一直觉得RAID 5在数据库里是个“看起来很美”的选择。容量利用率高测试环境跑起来好像也没问题但一旦写入压力上来奇偶校验的计算和额外写回会造成明显的性能抖动。以前帮一个项目排查数据库卡顿存储层就是RAID 5每次批量导入数据时底层磁盘队列深度一直很高应用侧查询全部排队。后来把数据文件迁到RAID 10的卷上同样导入任务时间缩短了将近一半。2.2 热备盘与重建窗口RAID最大的隐患不在平时而在磁盘故障后的重建过程。比如RAID 5阵列一块盘坏了换上热备盘后阵列要把剩下所有盘的数据重新计算并写入新盘这个过程叫重建。问题在于现在的单盘容量动不动就十几TB重建时间可能长达几十个小时。重建期间整个阵列还要承担正常的读写流量性能会下降而且如果这个过程中再有一块盘出问题数据就会彻底丢失。所以在设计存储方案时除了选对RAID级别还要考虑重建窗口能不能接受以及是否有备用容量。我个人的经验是关键业务库不要追求极致的容量利用率。多花点磁盘成本换重建速度和故障风险下降在运维层面是划算的。磁盘便宜数据重建的时间和人员成本才贵。2.3 硬件RAID与软件RAIDRAID可以实现为硬件RAID卡也可以由操作系统内核的软件模块实现。硬件RAID卡通常带独立缓存和掉电保护出现断电时能把缓存里的数据刷回磁盘性能和安全性都有保障。软件RAID成本低配置灵活但所有计算都消耗CPU而且没有独立掉电保护断电时更容易遇到不一致问题。数据库场景里如果条件允许核心数据库一般选硬件RAID卡并且开启写缓存。但要注意RAID卡的缓存策略如果设置成write-through写入性能会大打折扣设置成write-back又必须确保电池或电容没有故障。我见过不止一次因为RAID卡电池老化不得不把缓存模式降级结果数据库写入延迟翻倍的情况。3. 文件怎么摆堆、顺序、散列3.1 文件组织方式数据库的表最终要落到文件里文件里的记录怎么排列决定了查询要走多少IO。最基础的是堆文件记录就按插入顺序往里放新记录通常追加到文件末尾。堆文件的优点是插入效率高、简单缺点是按某字段查询时只能全表扫描或者依赖索引去定位文件本身不提供顺序访问的捷径。顺序文件则按某个字段的逻辑顺序存放记录。它适合范围查询比如按时间排序的流水表如果你希望连续读取某一时间段的数据顺序文件能明显减少磁盘寻道。维护顺序的代价是插入和删除都可能引发大量记录移动实际数据库很少用纯顺序文件存表这类需求更多交给索引结构来实现。散列文件通过散列函数把记录分布到固定的桶里点查性能优秀但范围查询很尴尬因为相邻的键值可能散落到完全不同的桶里需要把所有桶都访问一遍。这里能看出一个核心权衡没有免费的午餐每种文件组织方式都在查询类型之间做取舍。3.2 记录表示文件里每条记录由多个字段组成字段是定长还是变长直接影响存储格式。定长记录最简单每个字段固定字节数记录在页面里可以按固定槽位存储访问时用偏移量直接定位。但实际业务很少全定长字符串字段长短不一就得分情况处理。变长记录需要额外保存字段偏移量通常是在记录头部维护一个偏移量数组字段真正的内容放在后面。读取时先查偏移量到正确位置。还有一个很容易忽略的细节NULL值的表示。很多人觉得NULL就是没值但存储层必须明确区分“空字符串”和“NULL”。实践中常用一个位图每一位表示某个字段是否为空。这个位图虽然小却决定了记录的解析逻辑如果设计不当更新一行记录时可能因为NULL位图放不下而触发页面结构调整。3.3 页与槽数据库文件内部按页组织页通常是8KB、16KB或32KB。表里的记录存储在页中页内使用“分槽页结构”来管理空间页头记录页面状态和槽位信息记录从页尾向前增长槽位从页头区域向后延伸。每条记录在数据库里有一个逻辑标识叫RID常用的形式就是“页号槽号”。索引里保存的就是这个标识查询时根据RID直接定位到物理位置。这个设计让索引与记录的物理位置解耦记录在页内移动时只要槽号不变索引就不需要更新。但如果记录大到必须迁移到别的页RID就变了所有引用这条记录的索引都要同步更新这是行迁移代价的根源。我在调优时经常看到因为页内记录频繁更新产生大量碎片和行迁移。解决办法是控制页的填充因子比如预留部分空间给更新操作减少记录被迫换页的概率。这个参数看起来不起眼对更新频繁的表影响却非常大。4. 缓冲管理把最热的数据留在内存里4.1 缓冲池与脏页数据库不会每次都去磁盘读页而是通过缓冲池把磁盘页缓存到内存。读请求先看页在不在缓冲池不在才去磁盘加载。写入也一样修改先发生在内存里的页副本这些页被标记为“脏页”之后再刷回磁盘。这个机制里有两个关键点固定和解除固定以及脏页管理。查询在处理某页时必须固定这个页防止它被替换策略驱逐出内存。处理完就解除固定。如果某个页被固定期间正好要被换出数据库会跳过它等解除固定再考虑回收。脏页则必须等它被刷盘之后才能替换否则内存里的修改就丢了。固定机制经常被忽略但它和死锁、慢查询都有关系。某些数据库连接持有页固定时间过长可能导致其他连接需要的页无法入池整体并发上不去。排查这类问题不能只看一个连接在做什么要关注缓冲池内部谁在占着页面不放。4.2 替换策略的坑经典的操作系统课程会讲LRU最近最少使用替换策略。数据库里如果直接用纯LRU会踩一个很明显的坑顺序扫描。假设你的应用正在执行一个大表的全表扫描每扫一个页都认为它“刚刚被使用过”这些大量一次性使用的页会把真正高频访问的页挤出缓冲池。等全表扫描结束原本热的数据已经不见了后续查询又要重新从磁盘加载性能一下就崩了。所以数据库的缓冲池替换策略不能只考虑LRU还要区分页的访问模式。很多数据库用类似时钟算法的方法给每个页维护一个引用位淘汰时优先替换没有被引用的页近似LRU但避免了“一次扫描把池子冲干净”的问题。理解这点对调参数很有帮助比如某些数据库把扫描到的页标记为“低优先级”就是让顺序扫描不污染真正的热数据。注意出现全表扫描慢不一定都要去加索引。如果频繁做报表类的大范围扫描先把扫描对缓冲池的污染控制住效果往往比硬加索引更明显。4.3 缓冲池调参缓冲池大小是最重要的数据库内存参数之一。给太小命中率上不去频繁读盘给太大操作系统页换出和数据库页换入会互相竞争反而引起抖动。常见做法是观察缓冲区命中率长期在99%以上说明池子够用如果只有90%甚至更低就要考虑是不是内存不足或者扫描太多。但命中率也不是越高越好内存有限时把高频数据留在池里比追求一个绝对值更有价值。我在实际项目里习惯结合响应时间变化来调整逐步增大缓存池观察同类查询的延迟是否明显改善如果加了内存但延迟没变说明瓶颈已经不在缓存池。5. 记录与文件结构里的隐藏细节5.1 页利用率与碎片页的空间利用率直接决定了读取效率。如果页内碎片太多同样的数据量需要更多页来保存扫描时IO自然变多。碎片来源主要是删除和变长更新。删除记录后页内空出来的空间可能由于大小不合适无法被新记录利用形成内部碎片。变长字段更新后如果分槽页结构不能有效合并空间也会越用越乱。解决碎片不是一个命令能一劳永逸的。可以先统计每个表的页平均利用率找到那些利用率长期偏低的表再执行压缩或重建操作。我见过一个流水表平时大量删除过期数据页利用率掉到百分之四五十每次全表统计查询都特别慢。重建之后同样查询的扫描量直接减半响应时间大幅下降。5.2 大对象BLOB、CLOB这类大字段的存储是文件结构里一个独立话题。超长字段直接塞在记录里会让一个页只能放几行记录页利用率非常差还会连累普通字段的访问。通用的做法是把大对象单独存储记录本身只保存一个引用或标识真正的大内容放到独立的存储区域。更进一步的实践是不要把特别大的二进制都塞进数据库。我处理过一个上传文件存数据库的项目一个表里动辄几MB的文件内容数据库的备份变得异常庞大IO也被拖垮。后来改成把文件落到对象存储数据库只存路径线上负载立刻恢复正常。数据库擅长的是事务和查询不是当文件服务器。5.3 表扫描与预读全表扫描虽然经常被当成反面教材但它仍然是某些业务场景下最合理的方式比如没有合适索引、数据量本身不大、或者查询要访问大部分记录。这时候数据库会通过预读和顺序多块读取来优化扫描性能。预读的基本思路是检测到连续读多个顺序页时不等应用逐个请求直接把后续一批页也加载到缓冲池。这样磁盘磁头可以在顺序位置上连续工作避免来回寻道。在SSD上顺序预读的意义没那么大但依然存在因为可以减少IO请求数量、降低软件开销。如果发现某项业务的表扫描经常出现可以先确认扫描读取的是不是连续的物理页。因为频繁更新或碎片化之后逻辑相邻的页可能物理分散预读效率会下降。这种情况压缩整理文件往往比改SQL更见效。6. 实操中容易踩的坑和排查思路6.1 常见问题速查表现象可能原因排查方向单条查询不慢并发上去就卡磁盘随机IOPS耗尽iostat看await是否持续上升计算当前IOPS是否接近设备上限数据库突然大幅变慢几分钟后恢复后台全表扫描或备份任务冲击IO排查定时任务看是否与扫描时间吻合更新频繁的表越来越大查询却更慢页碎片和行迁移统计页利用率压缩重建大表缓冲池命中率很高但写入仍慢日志盘或RAID写缓存策略问题检查日志盘的写入延迟确认RAID缓存模式重启后数据库恢复特别慢缓冲池冷启动大量热页需重载考虑预热机制避免重启后立即接大流量磁盘没满但写不进去文件系统inode耗尽或磁盘故障检查inode使用率查看磁盘SMART状态这些问题的共同点是表面上都是“数据库慢”根子却在存储结构。定位时不要一上来就改写SQL先看一眼底层存储状态能省很多时间。6.2 几条实操心得做存储层调优监控数据一定要连续看几天的趋势而不是只看某一天的快照。磁盘高负载可能是历史备份、批量任务、业务高峰重叠造成的单点数据容易误判。压测要有针对性。不要只测顺序读写也不要只测大块IO。数据库的生产负载永远是随机小块读写和顺序大块扫描的混合体。用不同块大小和队列深度各跑一轮才能还原真实压力。日志文件和数据文件尽量分盘放。日志是顺序写为主对延迟特别敏感数据文件是随机读写为主对IOPS要求高。混在一起任何一个变慢都会拖累另一个。这在文件结构设计层面就是最简单的隔离手段。最后说一个我自己的体会很多存储问题的根源并不是硬件不行而是我们对数据访问模式的预期错了。一个表是不是按顺序成长的索引到底能不能减少随机跳转缓冲池够不够覆盖热数据这些在设计表结构时就应该想清楚。教材里第十章的内容看似偏底层实际每个概念都和线上数据库的行为直接挂钩。读的时候多问自己一句“如果这个机制失效会怎样”很多调优经验就自然串起来了。
聊到数据库大多数人第一反应是SQL写法、索引设计、优化器行为。但真正跑过线上系统的人都明白一台数据库在压力下是稳如老狗还是彻底卡死胜负手往往不在SQL而在存储这一层。这段时间我把《数据库系统概念》第十章“存储和文件结构”重新过了一遍结合这几年做性能排查和容量规划踩过的坑整理成一份偏实战的笔记。这篇文章不讲虚的把存储介质、RAID、文件组织、缓冲管理这些概念全部落到“为什么会这样设计”和“线上遇到问题怎么判断”上。不管是正在学数据库原理的学生还是要处理慢查询和IO瓶颈的开发者这部分内容都能帮你少走弯路。1. 从存储介质看数据库的“快”与“慢”1.1 先理解存储层级教科书里给了一个很经典的存储层次寄存器、高速缓存、主存、闪存、磁盘、磁带。越往上速度越快、价格越贵、容量越小越往下则反过来。数据库系统之所以要把数据分层放置核心原因就两个成本和持久性。如果把所有数据都放内存性能当然好看但容量上不去价格也扛不住更关键的是内存断电就没。所以数据库设计的基本盘是内存用来放热数据和临时计算结果磁盘或闪存用来放全部持久化数据。这个分层思路贯穿了整个数据库体系结构连查询优化器都要考虑“数据在内存还是磁盘”来决定执行策略。实际工作里最常见的误区是把“内存命中率”看成唯一指标。其实存储介质本身的延迟差异才是根因。一次内存访问大约是几十纳秒级别一次SSD随机读是几十微秒而一次机械盘随机读往往是几毫秒。这几个数量级的差距决定了SQL能不能扛住高并发。1.2 磁盘访问时间拆开算机械硬盘的访问时间可以拆成三部分寻道时间、旋转延迟、传输时间。寻道是磁头移动到目标磁道旋转延迟是等待目标扇区转到磁头下面传输时间则是数据真正读出写入的时间。这里有个经常被忽略的公式旋转延迟大约是磁盘转半圈的时间。一块7200转的盘每分钟7200转也就是每秒120转转一圈需要8.33毫秒半圈就是4.17毫秒左右。再加上常见的4到10毫秒寻道时间单次随机IO的延迟通常在8到15毫秒之间。这时候就能算出单盘机械硬盘的随机IOPS大概是多少1000毫秒除以10毫秒差不多就是100次每秒。这就是为什么机械盘做随机小IO非常吃力。很多教材喜欢直接给一个“随机IO比顺序IO慢几个数量级”的结论但我觉得更值得记住的是这个计算过程。因为当你用iostat看到某块盘await到了15毫秒以上你能立刻意识到这块盘的随机访问已经逼近物理极限了而不是去怀疑数据库配错了参数。1.3 闪存和SSD改变了很多事情SSD普及后存储延迟大幅度下降但闪存有自己的一套物理特性不能简单当成“快一点的磁盘”来用。NAND闪存的最小读写单位是页常见4KB到16KB但擦除操作的最小单位是块一个块包含多个页。这意味着你要改写某个页里的数据往往要把整个块读出来、擦除、再写回去。这就是常说的写放大问题。频繁的小写入实际落盘的数据量可能远大于应用层写入的数据量时间一长会加速闪存磨损。数据库场景里最容易踩SSD这个坑的就是日志写入。很多数据库默认日志刷新策略是每次提交都fsync一次产生大量4KB甚至更小的写。机械盘时代这么做是为了保事务SSD时代如果不对日志做合并和分组提交写放大就会非常明显。所以现代数据库都在做group commit把多个事务的日志刷盘合并成一次这不仅是CPU优化更是对闪存寿命的保护。另外SSD的随机读能力非常强但随机写仍然比随机读慢尤其是消费级SSD在没有掉电保护的情况下突然断电可能导致缓存里的数据丢失。这也是为什么生产环境数据库盘通常要选择带掉电保护的存储哪怕多花点钱。注意判断存储健康度时不要只盯“磁盘利用率util”这个指标。SSD因为内部并发高util到100%不代表真的满了还要结合队列深度和实际延迟一起看。单纯看util做告警容易出现误判。2. RAID别让一块盘的故障拖垮数据库2.1 RAID级别与数据库场景RAID的核心目标就两个提升性能、增强可靠性。不同级别在容量利用率、IOPS、写放大之间做取舍。RAID 0把数据条带化到多块盘容量和性能都能提升但没有任何冗余一块盘坏了数据全没。数据库几乎不用RAID 0除非你明确在做临时库或者丢了无所谓的数据。RAID 1是镜像每份数据写两份可靠性好但容量利用率只有50%。RAID 5用分布式奇偶校验允许坏一块盘容量利用率高但每次写都要额外计算和写入奇偶校验信息写惩罚明显。RAID 6允许坏两块盘可靠性更高但写入代价更重重建也慢。RAID 10是镜像加条带先做RAID 1再做条带化。它既保留了镜像的高可靠性又能通过条带化提升并发读写性能写惩罚相对可控。数据库生产环境用得最多的就是RAID 10尤其是存放核心数据文件的场景。我一直觉得RAID 5在数据库里是个“看起来很美”的选择。容量利用率高测试环境跑起来好像也没问题但一旦写入压力上来奇偶校验的计算和额外写回会造成明显的性能抖动。以前帮一个项目排查数据库卡顿存储层就是RAID 5每次批量导入数据时底层磁盘队列深度一直很高应用侧查询全部排队。后来把数据文件迁到RAID 10的卷上同样导入任务时间缩短了将近一半。2.2 热备盘与重建窗口RAID最大的隐患不在平时而在磁盘故障后的重建过程。比如RAID 5阵列一块盘坏了换上热备盘后阵列要把剩下所有盘的数据重新计算并写入新盘这个过程叫重建。问题在于现在的单盘容量动不动就十几TB重建时间可能长达几十个小时。重建期间整个阵列还要承担正常的读写流量性能会下降而且如果这个过程中再有一块盘出问题数据就会彻底丢失。所以在设计存储方案时除了选对RAID级别还要考虑重建窗口能不能接受以及是否有备用容量。我个人的经验是关键业务库不要追求极致的容量利用率。多花点磁盘成本换重建速度和故障风险下降在运维层面是划算的。磁盘便宜数据重建的时间和人员成本才贵。2.3 硬件RAID与软件RAIDRAID可以实现为硬件RAID卡也可以由操作系统内核的软件模块实现。硬件RAID卡通常带独立缓存和掉电保护出现断电时能把缓存里的数据刷回磁盘性能和安全性都有保障。软件RAID成本低配置灵活但所有计算都消耗CPU而且没有独立掉电保护断电时更容易遇到不一致问题。数据库场景里如果条件允许核心数据库一般选硬件RAID卡并且开启写缓存。但要注意RAID卡的缓存策略如果设置成write-through写入性能会大打折扣设置成write-back又必须确保电池或电容没有故障。我见过不止一次因为RAID卡电池老化不得不把缓存模式降级结果数据库写入延迟翻倍的情况。3. 文件怎么摆堆、顺序、散列3.1 文件组织方式数据库的表最终要落到文件里文件里的记录怎么排列决定了查询要走多少IO。最基础的是堆文件记录就按插入顺序往里放新记录通常追加到文件末尾。堆文件的优点是插入效率高、简单缺点是按某字段查询时只能全表扫描或者依赖索引去定位文件本身不提供顺序访问的捷径。顺序文件则按某个字段的逻辑顺序存放记录。它适合范围查询比如按时间排序的流水表如果你希望连续读取某一时间段的数据顺序文件能明显减少磁盘寻道。维护顺序的代价是插入和删除都可能引发大量记录移动实际数据库很少用纯顺序文件存表这类需求更多交给索引结构来实现。散列文件通过散列函数把记录分布到固定的桶里点查性能优秀但范围查询很尴尬因为相邻的键值可能散落到完全不同的桶里需要把所有桶都访问一遍。这里能看出一个核心权衡没有免费的午餐每种文件组织方式都在查询类型之间做取舍。3.2 记录表示文件里每条记录由多个字段组成字段是定长还是变长直接影响存储格式。定长记录最简单每个字段固定字节数记录在页面里可以按固定槽位存储访问时用偏移量直接定位。但实际业务很少全定长字符串字段长短不一就得分情况处理。变长记录需要额外保存字段偏移量通常是在记录头部维护一个偏移量数组字段真正的内容放在后面。读取时先查偏移量到正确位置。还有一个很容易忽略的细节NULL值的表示。很多人觉得NULL就是没值但存储层必须明确区分“空字符串”和“NULL”。实践中常用一个位图每一位表示某个字段是否为空。这个位图虽然小却决定了记录的解析逻辑如果设计不当更新一行记录时可能因为NULL位图放不下而触发页面结构调整。3.3 页与槽数据库文件内部按页组织页通常是8KB、16KB或32KB。表里的记录存储在页中页内使用“分槽页结构”来管理空间页头记录页面状态和槽位信息记录从页尾向前增长槽位从页头区域向后延伸。每条记录在数据库里有一个逻辑标识叫RID常用的形式就是“页号槽号”。索引里保存的就是这个标识查询时根据RID直接定位到物理位置。这个设计让索引与记录的物理位置解耦记录在页内移动时只要槽号不变索引就不需要更新。但如果记录大到必须迁移到别的页RID就变了所有引用这条记录的索引都要同步更新这是行迁移代价的根源。我在调优时经常看到因为页内记录频繁更新产生大量碎片和行迁移。解决办法是控制页的填充因子比如预留部分空间给更新操作减少记录被迫换页的概率。这个参数看起来不起眼对更新频繁的表影响却非常大。4. 缓冲管理把最热的数据留在内存里4.1 缓冲池与脏页数据库不会每次都去磁盘读页而是通过缓冲池把磁盘页缓存到内存。读请求先看页在不在缓冲池不在才去磁盘加载。写入也一样修改先发生在内存里的页副本这些页被标记为“脏页”之后再刷回磁盘。这个机制里有两个关键点固定和解除固定以及脏页管理。查询在处理某页时必须固定这个页防止它被替换策略驱逐出内存。处理完就解除固定。如果某个页被固定期间正好要被换出数据库会跳过它等解除固定再考虑回收。脏页则必须等它被刷盘之后才能替换否则内存里的修改就丢了。固定机制经常被忽略但它和死锁、慢查询都有关系。某些数据库连接持有页固定时间过长可能导致其他连接需要的页无法入池整体并发上不去。排查这类问题不能只看一个连接在做什么要关注缓冲池内部谁在占着页面不放。4.2 替换策略的坑经典的操作系统课程会讲LRU最近最少使用替换策略。数据库里如果直接用纯LRU会踩一个很明显的坑顺序扫描。假设你的应用正在执行一个大表的全表扫描每扫一个页都认为它“刚刚被使用过”这些大量一次性使用的页会把真正高频访问的页挤出缓冲池。等全表扫描结束原本热的数据已经不见了后续查询又要重新从磁盘加载性能一下就崩了。所以数据库的缓冲池替换策略不能只考虑LRU还要区分页的访问模式。很多数据库用类似时钟算法的方法给每个页维护一个引用位淘汰时优先替换没有被引用的页近似LRU但避免了“一次扫描把池子冲干净”的问题。理解这点对调参数很有帮助比如某些数据库把扫描到的页标记为“低优先级”就是让顺序扫描不污染真正的热数据。注意出现全表扫描慢不一定都要去加索引。如果频繁做报表类的大范围扫描先把扫描对缓冲池的污染控制住效果往往比硬加索引更明显。4.3 缓冲池调参缓冲池大小是最重要的数据库内存参数之一。给太小命中率上不去频繁读盘给太大操作系统页换出和数据库页换入会互相竞争反而引起抖动。常见做法是观察缓冲区命中率长期在99%以上说明池子够用如果只有90%甚至更低就要考虑是不是内存不足或者扫描太多。但命中率也不是越高越好内存有限时把高频数据留在池里比追求一个绝对值更有价值。我在实际项目里习惯结合响应时间变化来调整逐步增大缓存池观察同类查询的延迟是否明显改善如果加了内存但延迟没变说明瓶颈已经不在缓存池。5. 记录与文件结构里的隐藏细节5.1 页利用率与碎片页的空间利用率直接决定了读取效率。如果页内碎片太多同样的数据量需要更多页来保存扫描时IO自然变多。碎片来源主要是删除和变长更新。删除记录后页内空出来的空间可能由于大小不合适无法被新记录利用形成内部碎片。变长字段更新后如果分槽页结构不能有效合并空间也会越用越乱。解决碎片不是一个命令能一劳永逸的。可以先统计每个表的页平均利用率找到那些利用率长期偏低的表再执行压缩或重建操作。我见过一个流水表平时大量删除过期数据页利用率掉到百分之四五十每次全表统计查询都特别慢。重建之后同样查询的扫描量直接减半响应时间大幅下降。5.2 大对象BLOB、CLOB这类大字段的存储是文件结构里一个独立话题。超长字段直接塞在记录里会让一个页只能放几行记录页利用率非常差还会连累普通字段的访问。通用的做法是把大对象单独存储记录本身只保存一个引用或标识真正的大内容放到独立的存储区域。更进一步的实践是不要把特别大的二进制都塞进数据库。我处理过一个上传文件存数据库的项目一个表里动辄几MB的文件内容数据库的备份变得异常庞大IO也被拖垮。后来改成把文件落到对象存储数据库只存路径线上负载立刻恢复正常。数据库擅长的是事务和查询不是当文件服务器。5.3 表扫描与预读全表扫描虽然经常被当成反面教材但它仍然是某些业务场景下最合理的方式比如没有合适索引、数据量本身不大、或者查询要访问大部分记录。这时候数据库会通过预读和顺序多块读取来优化扫描性能。预读的基本思路是检测到连续读多个顺序页时不等应用逐个请求直接把后续一批页也加载到缓冲池。这样磁盘磁头可以在顺序位置上连续工作避免来回寻道。在SSD上顺序预读的意义没那么大但依然存在因为可以减少IO请求数量、降低软件开销。如果发现某项业务的表扫描经常出现可以先确认扫描读取的是不是连续的物理页。因为频繁更新或碎片化之后逻辑相邻的页可能物理分散预读效率会下降。这种情况压缩整理文件往往比改SQL更见效。6. 实操中容易踩的坑和排查思路6.1 常见问题速查表现象可能原因排查方向单条查询不慢并发上去就卡磁盘随机IOPS耗尽iostat看await是否持续上升计算当前IOPS是否接近设备上限数据库突然大幅变慢几分钟后恢复后台全表扫描或备份任务冲击IO排查定时任务看是否与扫描时间吻合更新频繁的表越来越大查询却更慢页碎片和行迁移统计页利用率压缩重建大表缓冲池命中率很高但写入仍慢日志盘或RAID写缓存策略问题检查日志盘的写入延迟确认RAID缓存模式重启后数据库恢复特别慢缓冲池冷启动大量热页需重载考虑预热机制避免重启后立即接大流量磁盘没满但写不进去文件系统inode耗尽或磁盘故障检查inode使用率查看磁盘SMART状态这些问题的共同点是表面上都是“数据库慢”根子却在存储结构。定位时不要一上来就改写SQL先看一眼底层存储状态能省很多时间。6.2 几条实操心得做存储层调优监控数据一定要连续看几天的趋势而不是只看某一天的快照。磁盘高负载可能是历史备份、批量任务、业务高峰重叠造成的单点数据容易误判。压测要有针对性。不要只测顺序读写也不要只测大块IO。数据库的生产负载永远是随机小块读写和顺序大块扫描的混合体。用不同块大小和队列深度各跑一轮才能还原真实压力。日志文件和数据文件尽量分盘放。日志是顺序写为主对延迟特别敏感数据文件是随机读写为主对IOPS要求高。混在一起任何一个变慢都会拖累另一个。这在文件结构设计层面就是最简单的隔离手段。最后说一个我自己的体会很多存储问题的根源并不是硬件不行而是我们对数据访问模式的预期错了。一个表是不是按顺序成长的索引到底能不能减少随机跳转缓冲池够不够覆盖热数据这些在设计表结构时就应该想清楚。教材里第十章的内容看似偏底层实际每个概念都和线上数据库的行为直接挂钩。读的时候多问自己一句“如果这个机制失效会怎样”很多调优经验就自然串起来了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
