备案控制台
探索云世界
开发者社区 数据库 文章 正文

浅析InnoDB索引结构（2）

2022-06-04 51
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
简介： 浅析InnoDB索引结构


3.2 特点2：聚集索引非叶子节点存储指向子节点的指针

对上面的测试表继续写入新数据，直到聚集索引树从一层分裂成两层。

我们根据旧文 InnoDB表聚集索引层高什么时候发生变化 里的计算方式，推算出来预计一个叶子节点最多可存储111条记录，因此在插入第112条记录时，就会从一层高度分裂成两层高度。经过实测，也的确是如此。

[root@yejr.me] [innodb]>select count(*) from t1;
+----------+
| count(*) |
+----------+
|      112 |
+----------+

[root@yejr.me]# innblock innodb/t1.ibd scan 16
...
===INDEX_ID:238
level1 total block is (1)
block_no:     3,level:   1|*|
level0 total block is (2)
block_no:     5,level:   0|*|block_no:     6,level:   0|*|

此时可以看到根节点依旧是pageno=3，而叶子节点变成了[5, 6]两个page。由此可知，根节点上应该只有两条物理记录，存储着分别指向pageno=[5, 6]这两个page的指针。

我们解析下3号page，看看它的具体结构：

[root@yejr.me]# innodb_space -s ibdata1 -T innodb/t1 -p 3 page-dump

...
 records:
 {:format=>:compact,
 :offset=>125,
 :header=>
 {:next=>138,
 :type=>:node_pointer,
 :heap_number=>2,
 :n_owned=>0,
 :min_rec=>true, #第一条记录是min_key
 :deleted=>false,
 :nulls=>[],
 :lengths=>{},
 :externs=>[],
 :length=>5},
 :next=>138,
 :type=>:clustered,
 #第一条记录，只存储key值
 :key=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>1}],
 :row=>[],
 :sys=>[],
 :child_page_number=>5, #value值是指向的叶子节点pageno=5
 :length=>8} #整条记录消耗8字节，除去key值4字节外，指针也需要4字节
{:format=>:compact,
 :offset=>138,
 :header=>
 {:next=>112,
 :type=>:node_pointer,
 :heap_number=>3,
 :n_owned=>0,
 :min_rec=>false,
 :deleted=>false,
 :nulls=>[],
 :lengths=>{},
 :externs=>[],
 :length=>5},
 :next=>112,
 :type=>:clustered,
 #第二条记录，只存储key值
 :key=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>56}],
 :row=>[],
 :sys=>[],
 :child_page_number=>6, #value值是指向的叶子节点pageno=6
 :length=>8}

优化建议2: 索引列数据长度越小越好，这样索引树存储效率越高，在非叶子节点能存储越多数据，延缓索引树层高分裂的速度，平均搜索效率更高。


3.3 特点3：辅助索引同时会存储主键索引列值

在辅助索引中，总是同时会存储主键索引（或者说聚集索引）的列值，其作用就是在对辅助索引扫描时，可以从叶子节点直接得到对应的聚集索引值，并可根据该值回表查询获取行数据（如果需要回表查询的话）。这个特性也被称为Index Extensions（5.6版本之后的优化器新特性，详见 Use of Index Extensions）。

此外，在辅助索引的非叶子节点中，索引记录的key值是索引定义的列值，而对应的value值则是聚集索引列值（简称PKV）。如果辅助索引定义时已经包含了部分聚集索引列，则索引记录的value值是未被包含的余下的聚集索引列值。

创建如下测试表：

CREATE TABLE `t3` (
  `a` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `b` int(10) unsigned NOT NULL DEFAULT '0',
  `c` varchar(20) NOT NULL DEFAULT '',
  `d` varchar(20) NOT NULL DEFAULT '',
  `e` varchar(20) NOT NULL DEFAULT '',
  PRIMARY KEY (`a`,`b`),
  KEY `k1` (`c`,`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

随机插入一些测试数据：

# 调用shell脚本写入500条数据
[root@yejr.me]# cat insert.sh
#!/bin/bash
. ~/.bash_profile
cd /data/perconad
i=1
max=500
while [ $i -le $max ]
do
 mysql -Smysql.sock -e "insert ignore into t3 select
    rand()1024, rand()1024, left(md5(uuid()),20) ,
    left(uuid(),20), left(uuid(),20);" innodb
 i=`expr $i + 1`
done

# 实际写入498条数据（其中有2条主键冲突失败）
[root@yejr.me] [innodb]>select count(*) from t3;
+----------+
| count(*) |
+----------+
|      498 |
+----------+

解析数据结构：

# 主键
[root@test1 perconad]# innodb_space -s ibdata1 -T innodb/t2 space-indexes
id    name     root  fseg        fseg_id   used   allocated   fill_factor
245   PRIMARY  3     internal    1         1      1           100.00%
245   PRIMARY  3     leaf        2         5      5           100.00%
246   k1       4     internal    3         1      1           100.00%
246   k1       4     leaf        4         2      2           1

[root@yejr.me]# innodb_space -s ibdata1 -T innodb/t2 -p 4 page-dump
...
records:
{:format=>:compact,
 :offset=>126,
 :header=>
  {:next=>164,
   :type=>:node_pointer,
   :heap_number=>2,
   :n_owned=>0,
   :min_rec=>true,
   :deleted=>false,
   :nulls=>[],
   :lengths=>{"c"=>20},
   :externs=>[],
   :length=>6},
 :next=>164,
 :type=>:secondary,
 :key=>
  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"00a5d42dd56632893b5f"},
   {:name=>"b", :type=>"INT UNSIGNED", :value=>323}],
 :row=>
  [{:name=>"a", :type=>"INT UNSIGNED", :value=>310},
   {:name=>"b", :type=>"INT UNSIGNED", :value=>9}],
   # 此处给解析成b列的值了，实际上是指向叶子节点的指针，即child_page_number=9
   # b列真实值是323
 :sys=>[],
 :child_page_number=>335544345,
 # 此处解析不准确，实际上是下一条记录的record header，共6个字节
 :length=>36}

{:format=>:compact,
 :offset=>164,
 :header=>
  {:next=>112,
   :type=>:node_pointer,
   :heap_number=>3,
   :n_owned=>0,
   :min_rec=>false,
   :deleted=>false,
   :nulls=>[],
   :lengths=>{"c"=>20},
   :externs=>[],
   :length=>6},
 :next=>112,
 :type=>:secondary,
 :key=>
  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"7458824a39892aa77e1a"},
   {:name=>"b", :type=>"INT UNSIGNED", :value=>887}],
 :row=>
  [{:name=>"a", :type=>"INT UNSIGNED", :value=>623},
   {:name=>"b", :type=>"INT UNSIGNED", :value=>10}],
   # 同上，其实是child_page_number=10，而非b列的值
 :sys=>[],
 :child_page_number=>0,
 :length=>36} #数据长度16字节

顺便说下，辅助索引上没存储TRX_ID, ROLL_PTR这些（他们只存储在聚集索引上）。

上面用innodb_ruby工具解析的非叶子节点部分内容不够准确，所以我们用二进制方式打开数据文件二次求证确认：

# 此处也可以用 hexdump 工具
[root@yejr.me]# vim -b path/t3.ibd
...
:%!xxd

# 找到辅助索引所在的那部分数据
0010050: 0002 0272 0000 00e1 0000 0002 01b2 0100  ...r............
0010060: 0200 1b69 6e66 696d 756d 0003 000b 0000  ...infimum......
0010070: 7375 7072 656d 756d 1410 0011 0026 3030  supremum.....&00
0010080: 6135 6434 3264 6435 3636 3332 3839 3362  a5d42dd56632893b
0010090: 3566 0000 0143 0000 0136 0000 0009 1400  5f...C...6......
00100a0: 0019 ffcc 3734 3538 3832 3461 3339 3839  ....7458824a3989
00100b0: 3261 6137 3765 3161 0000 0377 0000 026f  2aa77e1a...w...o
00100c0: 0000 000a 0000 0000 0000 0000 0000 0000  ................

# 参考page物理结构方式进行解析，得到下面的结果
/ 第一条记录 /
1410 0011 0026, record header, 5字节
3030 6135 6434 3264 6435 3636 3332 3839 3362 3566,c='00a5d42dd56632893b5f',20B
0000 0143, b=323, 4B
0000 0136, a=310, 4B
0000 0009, child_pageno=9, 4B

/ 2 /
1400 0019 ffcc, record header
3734 3538 3832 3461 3339 3839 3261 6137 3765 3161, c='7458824a39892aa77e1a'
0000 0377, b=887
0000 026f, a=623
0000 000a, child_pageno=10

现在反过来看，上面用innodb_ruby工具解析出来的page-dump结果应该是这样的才对（我只选取一条记录，请自行对比和之前的不同之处）：

{:format=>:compact,
 :offset=>164,
 :header=>
  {:next=>112,
   :type=>:node_pointer,
   :heap_number=>3,
   :n_owned=>0,
   :min_rec=>false,
   :deleted=>false,
   :nulls=>[],
   :lengths=>{"c"=>20},
   :externs=>[],
   :length=>6},
 :next=>112,
 :type=>:secondary,
 :key=>
  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"7458824a39892aa77e1a"},
   {:name=>"b", :type=>"INT UNSIGNED", :value=>887}],
 :row=> [{:name=>"a", :type=>"INT UNSIGNED", :value=>623}],
 :sys=>[],
 :child_page_number=>10,
 :length=>36}

可以看到，的确如前面所说，辅助索引的非叶子节点的value值存储的是聚集索引列值。

优化建议3：辅助索引列定义的长度越小越好，定义辅助索引时，没必要显式的加上聚集索引列（5.6版本之后）。


3.4 特点4：没有可用的聚集索引列时，会使用内置的ROW_ID作为聚集索引

创建几个像下面这样的表，使其选择内置的ROW_ID作为聚集索引：

[root@yejr.me] [innodb]> CREATE TABLE `tn1` (
  `c1` int(10) unsigned NOT NULL DEFAULT 0,
  `c2` int(10) unsigned NOT NULL DEFAULT 0
) ENGINE=InnoDB;

循环对几个表写数据：

insert into tt1 select 1,1;
insert into tt2 select 1,1;
insert into tt3 select 1,1;
insert into tt1 select 2,2;
insert into tt2 select 2,2;
insert into tt3 select 2,2;

查看 tn1 - tn3 表里的数据（这里由于innodb_ruby工具解析的结果不准确，所以我改用hexdump来分析）：

tn1
000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
000c080: 0003 1200 0000 003d f6aa 0000 01d9 0110  .......=........
000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
000c0a0: 0003 1500 0000 003d f9ad 0000 01da 0110  .......=........
000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................

tn2
000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
000c080: 0003 1300 0000 003d f7ab 0000 0122 0110  .......=....."..
000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
000c0a0: 0003 1600 0000 003d feb0 0000 01db 0110  .......=........
000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................

tn3
000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
000c080: 0003 1400 0000 003d f8ac 0000 0123 0110  .......=.....#..
000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
000c0a0: 0003 1700 0000 003e 03b3 0000 012a 0110  .......>.....*..
000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................

其中表示DB_ROW_ID的值分别是：

tn1
0003 12 => (1,1)
0003 15 => (2,2)

tn2
0003 13 => (1,1)
0003 16 => (2,2)

tn3
0003 14 => (1,1)
0003 17 => (2,2)

很明显，内置的DB_ROW_ID的确是在整个实例级别共享自增分配的，而不是每个表独享一个DB_ROW_ID序列。

我们可以想象下，如果一个实例中有多个表都用到这个DB_ROW_ID的话，势必会造成并发请求的竞争/等待。此外也可能会造成主从复制环境下，从库上relay log回放时可能会因为数据扫描机制的问题造成严重的复制延迟问题。详情参考 从库数据的查找和参数slave_rows_search_algorithms。

优化建议4：自行显示定义可用的聚集索引/主键索引，不要让InnoDB选择内置的DB_ROW_ID作为聚集索引，避免潜在的性能损失。

篇幅已经有点大了，本次的浅析工作就先到这里吧，以后再继续。


4、几点总结

最后针对InnoDB引擎表，总结几条建议吧。

  1. 每个表都要有显式主键，最好是自增整型，且没有业务用途
  2. 无论是主键索引，还是辅助索引，都尽可能选择数据类型较小的列
  3. 定义辅助索引时，没必要显式加上主键索引列（针对MySQL 5.6之后）
  4. 行数据越短越好，如果每个列都是固定长的则更好（不是像VARCHAR这样的可变长度类型）

上述测试环境基于Percona Server 5.7.22：

# MySQL的版本是Percona Server 5.7.22-22，我自己下载源码编译的
[root@yejr.me#] mysql -Smysql.sock innodb
...
Server version: 5.7.22-22-log Source distribution
...
[root@yejr.me]> \s
...
Server version:     5.7.22-22-log Source distribution

Enjoy MySQL :)

            </div>
文章标签：
云数据库 RDS MySQL 版
云解析DNS
测试技术
关系型数据库
索引
MySQL
存储
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境，其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
xaubllxwtvaqiu
目录
相关文章
小刘抒001
|
9月前
|
存储 关系型数据库 MySQL
InnoDB与MyISAM实现索引方式的区别
InnoDB和MyISAM是MySQL中常见的两种存储引擎，它们在实现索引方式上有一些区别。下面我将简述InnoDB和MyISAM实现索引的方式和特点。
小刘抒001
51 0
xaubllxwtvaqiu
|
存储 关系型数据库 MySQL
浅析InnoDB索引结构（2）
浅析InnoDB索引结构
xaubllxwtvaqiu
54 0
xaubllxwtvaqiu
|
存储 关系型数据库 索引
浅析InnoDB索引结构（1）
浅析InnoDB索引结构
xaubllxwtvaqiu
94 0
漫天花雨
|
关系型数据库 MySQL Linux
解读InnoDB页面--索引结构
前言 很久之前了解到innodb_space，觉得很强大，可视化了InnoDB页面，但是没有形成文档，总结出来，有一些经常被问到的东东可以用这个查看了。 环境 centos 7 Linux izhp3j8nb7nyq2g923r9fvz 3.
漫天花雨
1873 0
开放平台
|
4天前
|
弹性计算 安全 API
访问控制（RAM）｜云上安全使用AccessKey的最佳实践
集中管控AK/SK的生命周期，可以极大降低AK/SK管理和使用成本，同时通过加密和轮转的方式，保证AK/SK的安全使用，本次分享为您介绍产品原理，以及具体的使用步骤。
开放平台
101786 0
阿里云瑶池数据库
|
5天前
|
SQL 关系型数据库 分布式数据库
你的数据库用对索引了吗？一文揭秘PolarDB XPlan索引选择
深度解读PolarDB分布式版XPlan的索引选择
阿里云瑶池数据库
62522 2
你的数据库用对索引了吗？一文揭秘PolarDB XPlan索引选择
编程的平行世界
|
8天前
Doodle Jump — 使用Flutter&Flame开发游戏真不错！
用Flutter&Flame开发游戏是一种什么体验？最近网上冲浪的时候，我偶然发现了一个国外的游戏网站，类似于国内的4399。在浏览时，我遇到了一款经典的小游戏：Doodle Jump...
编程的平行世界
112707 8
开放平台
|
12天前
|
弹性计算 运维 安全
访问控制（RAM）｜云上程序使用临时凭证的最佳实践
STS临时访问凭证是阿里云提供的一种临时访问权限管理服务，通过STS获取可以自定义时效和访问权限的临时身份凭证，减少长期访问密钥（AccessKey）泄露的风险。本文将为您介绍产品原理，以及具体的使用步骤。
开放平台
151035 4
阿里云云原生
|
10天前
|
数据采集 存储 运维
提升团队工程交付能力，从“看见”工程活动和研发模式开始
本文从统一工程交付的概念模型开始，介绍了如何将应用交付的模式显式地定义出来，并通过工具平台落地。
阿里云云原生
119991 57
念广隶
|
11天前
|
监控 负载均衡 Java
深入探究Java微服务架构：Spring Cloud概论
**摘要：** 本文深入探讨了Java微服务架构中的Spring Cloud，解释了微服务架构如何解决传统单体架构的局限性，如松耦合、独立部署、可伸缩性和容错性。Spring Cloud作为一个基于Spring Boot的开源框架，提供了服务注册与发现、负载均衡、断路器、配置中心、API网关等组件，简化了微服务的开发、部署和管理。文章详细介绍了Spring Cloud的核心模块，如Eureka、Ribbon、Hystrix、Config、Zuul和Sleuth，并通过一个电商微服务系统的实战案例展示了如何使用Spring Cloud构建微服务应用。
念广隶
103505 8