其中 Infimum + supremum 以及 User Records 为页中存储数据的部分。其中 Infimum 表示页中的最小记录，而 supremum 表示页中的最大记录。这两个记录不存储实际的值，而仅仅表示开头以及结尾。User Records 部分按行存储数据。User Records 中的每一条记录格式为:
插入到页中的记录是按主键大小进行排序。利用其中的 next_record 可以查找到下一条记录。在不考虑索引的情况下，如果我们要寻找其中的某条记录可以通过遍历链表的方式进行查找。但是如果当页中的数据过多，o(n) 的时间复杂度明显不满足快速查找的需求。因此 InnoDB 在页中设计了页目录。页目录中有多个槽，其规则如下:
因此实际搜索时，可以利用槽进行二分搜索，将算法复杂度降到了 。这个结构有点类似于一个两层的跳跃表。
由于一个页中实际能存储的数据有限，因此记录会被分配到多个页进行存储。页与页之间有着双向链表的结构。
在 innodb 中使用 B+ 树作为索引。实际上索引在 mysql 中也是作为页进行管理的。例如:
索引页与数据页类似，只是索引页中一条记录只存在两列。分别是页对应的最我号，以及页的页编号。当然，一个 b+ 树肯定存在多个级别，因此实际上的存存储格式为:
这里可以看出索引页与数据页其实并没有太多的区别。只不过数据页中存储着真实的数据，而索引页只存储索引。这里也可以看出主键索引实际上是聚集索引，当查找到最终的数据页时是可以直接获得数据。
许多个页组成的空间之为页空间。每个表空间对应着一个真实的文件 表名.ibd。每一个独立表空间中又会分为多个区。每一个区实际上是 64 个连续的页组成。每256个区划又会分为一组。
为什么会提出区的概念呢？原因是查找数据的时候，在页与页之间会通过双向链表进行查找。如果两个页随机分配物理地址，则其之间的物理位置可能非常远。那么在查找的时候无疑会形成大量的随机 IO。降低磁盘的性能。因此，当表中数据过大的时候，以区为单位进行分配连续的磁盘空间，可以减少随机 IO 的数量。
表空间中还有段的概念，当我们利用索引进行查询的时候。很多时候实际上是利用 B+ 树的叶子节点进行范围扫描。但是如果将索引页和数据页都存放在一个区中，那么数据页不一定是连续的磁盘空间。因此当进行范围扫描的时候又会存在随机 IO 的情况。因此索引页和数据页实际上是存放在不同的区中。存放索引页的区的集合又成为一个段，当然非索引页存放的区的集合则为另一个段。
我们知道，磁盘的速度是远远小于内存的速度。因此 InnoDB 会将查询的页缓存在内存 Buffer Pool 中，以免每一次请求都从磁盘中获取，加快查询速度。当然，内存不可能无止尽的使用。因此 InnoDB维护了一个 free 链表。 free 链表指向 Buffer Pool 中可用的部分。
当页面进行修改之后，缓存的中的页页不会马上落盘，这样的页称为脏页。InnoDB 维护了一个 flush 链表指向了脏页。当 buffer 的空间不足时，InnoDB 会进行刷页 *** 作，将脏页写入到磁盘中，腾出内存空间供新的页缓存使用。
一般来说，数据有冷热之分。如果经常刷新热点数据到磁盘中，肯定不划算。因为热点数据经常被查询修改，当写入到磁盘中后又会很快读入到缓存中，做了很多无用功。因此 InnoDB 采用了 LRU 算法统计哪些是热点数据，哪些是非热点数据。每次刷盘时从首先 LRU 链表的尾部将热点数据刷入到磁盘中。
InnoDB 并不是采用最简单的链表，而是划分区域的链表。其设计的原因是，InnoDB 在某些时候会采取预读的 *** 作，将一个区的数据全部读入到内存中。这些数据就会出现在 LRU 链表的头部。如果这些预读的数据最终不能被查询，那么真正的热点数据反而被挤到了链表的尾部，这样一旦存在预读行为 LRU 链表的功能就丧失了。同样，当用户进行扫描全表的 *** 作时，大量的页也会被加载到缓存中将 Buffer 占满。因此 InnoDB 将 LRU 分为两个区域-热数据(young 区)以及冷数据(old 区)。
对于第一种情况，当页被缓存到 Buffer 时首先会被放在 old 区。如果该页后续被继续访问，则会被放到 young 区中。而如果该页后续没有被继续访问到，则会逐渐移动到 old 区尾部。
对于扫描全表的情况，扫描全表有一个特点。即页中的每一条数据都会被访问到，同一个页第一次访问到最后一次访问的间隔时间一定很短。因此 InnoDB 设计了一个策略，如果当一个页加载到内存中，并且该页在第一此访问与最后一次访问间隔相差小于 1s (默认值)，则该页就不会被加入到 young 区中。因此这种方式可以避免全表扫描时对 LRU 链表的污染。
我的主机内存只有100G，现在要全表扫描一个200G大表，会不会把DB主机的内存用光？
逻辑备份时，可不就是做整库扫描吗？若这样就会把内存吃光，逻辑备份不是早就挂了？
所以大表全表扫描，看起来应该没问题。这是为啥呢？
假设，我们现在要对一个200G的InnoDB表db1. t，执行一个全表扫描。当然，你要把扫描结果保存在客户端，会使用类似这样的命令：
InnoDB数据保存在主键索引上，所以全表扫描实际上是直接扫描表t的主键索引。这条查询语句由于没有其他判断条件，所以查到的每一行都可以直接放到结果集，然后返回给客户端。
那么，这个“结果集”存在哪里呢？
服务端无需保存一个完整结果集。取数据和发数据的流程是这样的：
查询结果发送流程
可见：
所以MySQL其实是“边读边发”。这意味着，若客户端接收得慢，会导致MySQL服务端由于结果发不出去，这个事务的执行时间变长。
比如下面这个状态，就是当客户端不读 socket receive buffer 内容时，在服务端show processlist看到的结果。
若看到State一直是“Sending to client”，说明服务器端的网络栈写满了。
若客户端使用–quick参数，会使用mysql_use_result方法：读一行处理一行。假设某业务的逻辑较复杂，每读一行数据以后要处理的逻辑若很慢，就会导致客户端要过很久才取下一行数据，可能就会出现上图结果。
因此，对于正常的线上业务来说，若一个查询的返回结果不多，推荐使用mysql_store_result接口，直接把查询结果保存到本地内存。
当然前提是查询返回结果不多。如果太多，因为执行了一个大查询导致客户端占用内存近20G，这种情况下就需要改用mysql_use_result接口。
若你在自己负责维护的MySQL里看到很多个线程都处于“Sending to client”，表明你要让业务开发同学优化查询结果，并评估这么多的返回结果是否合理。
若要快速减少处于这个状态的线程的话，可以将net_buffer_length设置更大。
有时，实例上看到很多查询语句状态是“Sending data”，但查看网络也没什么问题，为什么Sending data要这么久？
一个查询语句的状态变化是这样的：
即“Sending data”并不一定是指“正在发送数据”，而可能是处于执行器过程中的任意阶段。比如，你可以构造一个锁等待场景，就能看到Sending data状态。
读全表被锁：
Sending data状态
可见session2是在等锁，状态显示为Sending data。
所以，查询的结果是分段发给客户端，因此扫描全表，查询返回大量数据，并不会把内存打爆。
以上是server层的处理逻辑，在InnoDB引擎里又是怎么处理？
InnoDB内存的一个作用，是保存更新的结果，再配合redo log，避免随机写盘。
内存的数据页是在Buffer Pool (简称为BP)管理，在WAL里BP起加速更新的作用。
BP还能加速查询。
而BP对查询的加速效果，依赖于一个重要的指标，即：内存命中率。
可以在show engine innodb status结果中，查看一个系统当前的BP命中率。一般情况下，一个稳定服务的线上系统，要保证响应时间符合要求的话，内存命中率要在99%以上。
执行show engine innodb status ，可以看到“Buffer pool hit rate”字样，显示的就是当前的命中率。比如下图命中率，就是100%。
若所有查询需要的数据页都能够直接从内存得到，那是最好的，对应命中率100%。
InnoDB Buffer Pool的大小是由参数 innodb_buffer_pool_size确定，一般建议设置成可用物理内存的60%~80%。
在大约十年前，单机的数据量是上百个G，而物理内存是几个G；现在虽然很多服务器都能有128G甚至更高的内存，但是单机的数据量却达到了T级别。
所以，innodb_buffer_pool_size小于磁盘数据量很常见。若一个 Buffer Pool满了，而又要从磁盘读入一个数据页，那肯定是要淘汰一个旧数据页的。
使用的最近最少使用 (Least Recently Used, LRU)算法，淘汰最久未使用数据。
InnoDB管理BP的LRU算法，是用链表实现的：
最终就是最久没有被访问的数据页Pm被淘汰。
若此时要做一个全表扫描，会怎样？若要扫描一个200G的表，而这个表是一个历史数据表，平时没有业务访问它。
那么，按此算法扫描，就会把当前BP里的数据全部淘汰，存入扫描过程中访问到的数据页的内容。也就是说BP里主要放的是这个历史数据表的数据。
对于一个正在做业务服务的库，这可不行呀。你会看到，BP内存命中率急剧下降，磁盘压力增加，SQL语句响应变慢。
所以，InnoDB不能直接使用原始的LRU。InnoDB对其进行了优化。
InnoDB按5:3比例把链表分成New区和Old区。图中LRU_old指向的就是old区域的第一个位置，是整个链表的5/8处。即靠近链表头部的5/8是New区域，靠近链表尾部的3/8是old区域。
改进后的LRU算法执行流程：
该策略，就是为了处理类似全表扫描的 *** 作量身定制。还是扫描200G历史数据表：
可以看到，这个策略最大的收益，就是在扫描这个大表的过程中，虽然也用到了BP，但对young区完全没有影响，从而保证了Buffer Pool响应正常业务的查询命中率。
MySQL采用的是边算边发的逻辑，因此对于数据量很大的查询结果来说，不会在server端保存完整的结果集。所以，如果客户端读结果不及时，会堵住MySQL的查询过程，但是不会把内存打爆。
而对于InnoDB引擎内部，由于有淘汰策略，大查询也不会导致内存暴涨。并且，由于InnoDB对LRU算法做了改进，冷数据的全表扫描，对Buffer Pool的影响也能做到可控。
全表扫描还是比较耗费IO资源的，所以业务高峰期还是不能直接在线上主库执行全表扫描的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）