首页
AI Coding
NEW
沸点
课程
直播
活动
AI刷题
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
会员
登录
注册
MySQL
程序员小潘
创建于2022-02-22
订阅专栏
MySQL关系型数据库
等 1 人订阅
共11篇文章
创建于2022-02-22
订阅专栏
默认顺序
默认顺序
最早发布
最新发布
InnoDB之redo log写入和恢复
InnoDB使用Buffer Pool来加速数据读写,提升性能的同时也带来了一些问题,为了避免页面频繁刷盘和磁盘随机写
InnoDB之redo log格式
本文正在参加「金石计划 . 瓜分6万现金大奖」 1. redo log作用 MySQL有一个组件叫Buffer Pool,它通过内存来缓存磁盘里的数据页,来提升数据读写性能。所有数据的读写首先经过Bu
InnoDB缓存之Buffer Pool
1. 前言 我们已经知道,对于InnoDB存储引擎而言,页是磁盘和内存交互的基本单位。哪怕你要读取一条记录,InnoDB也会将整个索引页加载到内存。哪怕你只改了1个字节的数据,该索引页就是脏页了,整个
MySQL执行成本是如何计算的?
1. 前言 我们知道,全表扫描适用于任何查询,这是最简单也是最笨拙的一种查询方式,它的缺点是当表中数据量较大时性能就会非常差,因为需要扫描整棵聚簇索引B+树的叶子节点,涉及到大量的磁盘IO和CPU计算
MySQL表连接算法
1. 前言 MySQL属于关系型数据库,我们建的表大多也都存在业务上的关联关系,同时我们又不可能将所有的数据都冗余一份,这不符合数据库的设计范式。因此,当我们需要把多张表的数据融合在一起的时候,就需要
MySQL优化之Index Merge
1. 前言 先问大家一个问题,在不考虑多表联查这种复杂的查询场景下,一个简单的单表查询,MySQL可以同时利用几个索引? 当初我学习MySQL的时候,天真的以为只要把WHERE条件涉及到的列全部加
InnoDB表空间之段的概念
1. 前言 通过前面的文章,我们已经知道了索引页的结构可以使得它们不用在物理上连续也能正常工作,只是不连续会导致大量的随机IO性能较差,为了解决这个问题InnoDB引入了区的概念,物理上连续的64个页
InnoDB表空间之区的概念
1. 前言 目前为止我们已经知道,「行格式」决定了记录在磁盘中的存储格式,记录通过头信息里的指针串联成单向链表。为了更好的管理记录,InnoDB使用「页」为基本单位来存储记录,页与页之间串联成双向链表
MySQL行格式
1. 前言 MySQL架构分为Server层和存储引擎层,Server层负责接收处理客户端指令,一旦涉及到数据的读取和写入操作,最终是需要调用存储引擎提供的接口来完成的。在MySQL的整个生态里,除M
InnoDB表数据的组织形式:B+树
1. 前言 通过「行格式」我们知道了记录在磁盘里的存储格式,除了存储记录的真实数据外,每条记录还会有额外的头信息、变长字段长度列表、NULL值列表等信息。为了更好的管理记录,InnoDB以「页」为基本
MySQL索引页结构
1. 前言 「页」是InnoDB管理存储空间的基本单位,也是内存和磁盘交互的基本单位。也就是说,哪怕你需要1字节的数据,InnoDB也会读取整个页的数据,下次读取的数据如果恰巧也在这个页里,就能命中缓