原来我沿着“内存磁盘、页、区、段”往下学概念都见过却容易把它们当成一串固定公式。这次换一个问题串起来按主键查一条记录为什么不一定读磁盘也不需要把整张表加载进内存本文按MySQL 8.4官方文档核对概念原图保留为历史学习图。涉及16KiB与64页的图都只代表该页大小下的示例不是所有配置的固定常量。本轮没有可用的MySQL实例不编造执行结果或磁盘测量。1. 一次查找是找页并检查页是否已在缓存SELECT name FROM orders WHERE id 1001;这是一条说明主键查找的示意SQL假设orders使用InnoDB且id是主键未提供该表就不能直接运行。索引访问要用到的页可能已经在Buffer Pool中也可能需要读入命中后可以直接使用缓存页不等于整个请求从此没有任何其他I/O。未命中也不是“一行对应一次固定磁盘I/O”查找可能涉及多个页读入一个页又可以服务多条记录。Buffer Pool官方说明。索引访问需要某个页 - Buffer Pool已有它使用缓存页 - 尚未缓存请求读入之后再访问页内记录原文“所有数据库操作都在内存完成最后刷回磁盘”过于宽泛。对InnoDB数据页的访问、修改通常围绕Buffer Pool展开但还有日志、文件管理和其他引擎等工作不能用一个句子包办整个数据库。2. .ibd与表空间数据和索引都在里面这张图可说明旧环境的文件组织但包含.frm不能称为MySQL 8.4的现场截图。表空间是InnoDB管理存储的逻辑对象文件是它在文件系统上的承载也不是所有表都必须各自只有一个.ibd。在file-per-table配置下普通单表的表数据和索引放在相应的.ibd文件中。系统、通用、undo、临时表空间用途不同原文写的“五类表”应是表空间类别而不是五种业务表。通用表空间还可以容纳多张表。独立表空间官方说明。innodb_file_per_table影响新建表的相关行为改变它不会自动迁移所有已经存在的表。本篇只读配置不建议读者为了对照图去修改线上全局变量或移动数据库文件。3. 页是访问单位区是空间分配单位原图“读取到内存”的箭头只表示层次关系不表示任意查一行都会预读整个区。是否预读以及读多少要看访问和策略。MySQL 8.4文档中的常规页/区配置为innodb_page_size区大小每区页数4KiB1MiB2568KiB1MiB12816KiB1MiB6432KiB2MiB6464KiB4MiB64所以需要限定的是“1MiB64页”这个组合而不是声称1MiB只在16KiB页下出现。页大小在初始化实例时确定不能把它当作每张表随意修改的运行时旋钮。文件空间管理页大小参数。区里的连续页首先描述表空间地址和分配组织。文件系统、存储设备还会映射这些位置不能据此保证机械磁盘上绝对连续更不能对SSD都用“磁头移动”解释性能。4. 段是按用途管理空间不是再包一层连续地址原文把“建表初始6或7页”和“先分配32页”混在一起。前者依具体版本、表和文件初始化细节而变不能在没有现场观察时写成固定结论后者是在描述段增长时先逐页分配再转向整区分配的空间管理策略不是每张表都固定只占32页。原图中的“256个区为一个区组”保留为当时16KiB格式的管理示意不升级为覆盖所有页大小的通用数字。查页级布局时应继续追对应版本的XDES等元数据而不是把group硬拼成所有结构必有的一层容器。原图想表达的是索引树不同用途的页分别管理不要求段在文件中是连续区间。也别把“叶子段就是完整用户行”泛化到所有索引聚簇索引叶子保存行数据二级索引叶子组织的是相应索引记录。聚簇与二级索引官方说明。5. 真正观察配置时从只读查询开始以下是给有MySQL实例时的观察清单不是本轮输出截图。它不建表、不改全局配置权限不足或版本不同要记录实际错误别凭空补结果。SELECT VERSION(); SHOW VARIABLES LIKE innodb_page_size; SHOW VARIABLES LIKE innodb_file_per_table; SHOW VARIABLES LIKE innodb_buffer_pool_size; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;两个计数可帮助观察逻辑读请求与物理读情况但GLOBAL状态受其他会话、预读和后台活动影响。不能看一次查询前后相差1就宣称“该查询精确发生一次磁盘读取”更不能把累计比值拿来当这条SQL的独立命中率。要做冷热对照应使用隔离实验实例、记录版本、配置与并发选择有明确数据规模的查询。不在生产库清空缓存来制造冷读也不把重复查询跑得快直接解释成“缓存了整张表”。6. 回头看这几张图各自回答什么目录图回答数据可能承载在哪里页/区图回答空间怎样组织段图回答按何种用途管理Buffer Pool回答访问时是否需要把页读入内存。它们有关联但不是“一个SQL必经一次整个区到内存”的机械流程。本次完成原图阅读和官方概念核对未执行本节MySQL观察查询未解析真实.ibd或验证页头字节。页目录、行格式与记录头的字节级细节留给存储结构篇继续核对不用一个教学图替代真实文件格式证据。 InnoDB存储引擎：从一条查询串起Buffer Pool、页、区与表空间
原来我沿着“内存磁盘、页、区、段”往下学概念都见过却容易把它们当成一串固定公式。这次换一个问题串起来按主键查一条记录为什么不一定读磁盘也不需要把整张表加载进内存本文按MySQL 8.4官方文档核对概念原图保留为历史学习图。涉及16KiB与64页的图都只代表该页大小下的示例不是所有配置的固定常量。本轮没有可用的MySQL实例不编造执行结果或磁盘测量。1. 一次查找是找页并检查页是否已在缓存SELECT name FROM orders WHERE id 1001;这是一条说明主键查找的示意SQL假设orders使用InnoDB且id是主键未提供该表就不能直接运行。索引访问要用到的页可能已经在Buffer Pool中也可能需要读入命中后可以直接使用缓存页不等于整个请求从此没有任何其他I/O。未命中也不是“一行对应一次固定磁盘I/O”查找可能涉及多个页读入一个页又可以服务多条记录。Buffer Pool官方说明。索引访问需要某个页 - Buffer Pool已有它使用缓存页 - 尚未缓存请求读入之后再访问页内记录原文“所有数据库操作都在内存完成最后刷回磁盘”过于宽泛。对InnoDB数据页的访问、修改通常围绕Buffer Pool展开但还有日志、文件管理和其他引擎等工作不能用一个句子包办整个数据库。2. .ibd与表空间数据和索引都在里面这张图可说明旧环境的文件组织但包含.frm不能称为MySQL 8.4的现场截图。表空间是InnoDB管理存储的逻辑对象文件是它在文件系统上的承载也不是所有表都必须各自只有一个.ibd。在file-per-table配置下普通单表的表数据和索引放在相应的.ibd文件中。系统、通用、undo、临时表空间用途不同原文写的“五类表”应是表空间类别而不是五种业务表。通用表空间还可以容纳多张表。独立表空间官方说明。innodb_file_per_table影响新建表的相关行为改变它不会自动迁移所有已经存在的表。本篇只读配置不建议读者为了对照图去修改线上全局变量或移动数据库文件。3. 页是访问单位区是空间分配单位原图“读取到内存”的箭头只表示层次关系不表示任意查一行都会预读整个区。是否预读以及读多少要看访问和策略。MySQL 8.4文档中的常规页/区配置为innodb_page_size区大小每区页数4KiB1MiB2568KiB1MiB12816KiB1MiB6432KiB2MiB6464KiB4MiB64所以需要限定的是“1MiB64页”这个组合而不是声称1MiB只在16KiB页下出现。页大小在初始化实例时确定不能把它当作每张表随意修改的运行时旋钮。文件空间管理页大小参数。区里的连续页首先描述表空间地址和分配组织。文件系统、存储设备还会映射这些位置不能据此保证机械磁盘上绝对连续更不能对SSD都用“磁头移动”解释性能。4. 段是按用途管理空间不是再包一层连续地址原文把“建表初始6或7页”和“先分配32页”混在一起。前者依具体版本、表和文件初始化细节而变不能在没有现场观察时写成固定结论后者是在描述段增长时先逐页分配再转向整区分配的空间管理策略不是每张表都固定只占32页。原图中的“256个区为一个区组”保留为当时16KiB格式的管理示意不升级为覆盖所有页大小的通用数字。查页级布局时应继续追对应版本的XDES等元数据而不是把group硬拼成所有结构必有的一层容器。原图想表达的是索引树不同用途的页分别管理不要求段在文件中是连续区间。也别把“叶子段就是完整用户行”泛化到所有索引聚簇索引叶子保存行数据二级索引叶子组织的是相应索引记录。聚簇与二级索引官方说明。5. 真正观察配置时从只读查询开始以下是给有MySQL实例时的观察清单不是本轮输出截图。它不建表、不改全局配置权限不足或版本不同要记录实际错误别凭空补结果。SELECT VERSION(); SHOW VARIABLES LIKE innodb_page_size; SHOW VARIABLES LIKE innodb_file_per_table; SHOW VARIABLES LIKE innodb_buffer_pool_size; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;两个计数可帮助观察逻辑读请求与物理读情况但GLOBAL状态受其他会话、预读和后台活动影响。不能看一次查询前后相差1就宣称“该查询精确发生一次磁盘读取”更不能把累计比值拿来当这条SQL的独立命中率。要做冷热对照应使用隔离实验实例、记录版本、配置与并发选择有明确数据规模的查询。不在生产库清空缓存来制造冷读也不把重复查询跑得快直接解释成“缓存了整张表”。6. 回头看这几张图各自回答什么目录图回答数据可能承载在哪里页/区图回答空间怎样组织段图回答按何种用途管理Buffer Pool回答访问时是否需要把页读入内存。它们有关联但不是“一个SQL必经一次整个区到内存”的机械流程。本次完成原图阅读和官方概念核对未执行本节MySQL观察查询未解析真实.ibd或验证页头字节。页目录、行格式与记录头的字节级细节留给存储结构篇继续核对不用一个教学图替代真实文件格式证据。