InnoDB索引允许NULL对性能有影响吗(2)

简介: InnoDB索引允许NULL对性能有影响吗


这次的查询需要扫描12个page,除去1个根节点外,还需要扫描12个叶子节点,只是为了返回一条数据而已,这代价有点大。

如果把SQL微调改成下面这样

[root@yejr.run]> select id,c1 from t_sk where c1 is null limit 10000,1;
+-------+------+
| id    | c1   |
+-------+------+
| 99671 | NULL |
+-------+------+



可以看到还是需要扫描12个page。

InnoDB_pages_distinct: 12

...
select id,c1 from t_sk where c1 is null limit 10000,1;



SQL3, 查询 c1 任意非NULL值

如果把 c1列条件改成正常的int值,结果就不太一样了

[root@yejr.run]> select id, c1 from t_sk where c1  = 907299016;
+--------+-----------+
| id | c1 |
+--------+-----------+
| 365115 | 907299016 |
+--------+-----------+
1 row in set (0.00 sec)

slow log是这样的

InnoDB_pages_distinct: 2
...
select id, c1 from t_sk where c1 = 907299016;



可以看到,只需要扫描2个page,这个看起来就正常了。

结论1,存储大量的NULL值,除了计算更复杂之外,数据扫描的代价也会更高一些


另外,如果要查询的c1值正好介于两个page的临界位置,那么需要多读取一个page。

扫描第31号page,确认该数据页中的最小和最大物理记录

[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -p 31 page-dump
...
records:
{:format=>:compact,
:offset=>126,
:header=>
{:next=>9996,
:type=>:conventional,
:heap_number=>2,
:n_owned=>0,
:min_rec=>false,
:deleted=>false,
:nulls=>[],
:lengths=>{},
:externs=>[],
:length=>6},
:next=>9996,
:type=>:secondary,
:key=>[{:name=>"c1", :type=>"INT UNSIGNED", :value=>1531865685}],
:row=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>1507}],
:sys=>[],
:length=>8}
...
{:format=>:compact,
:offset=>5810,
:header=>
{:next=>112,
:type=>:conventional,
:heap_number=>408,
:n_owned=>0,
:min_rec=>false,
:deleted=>false,
:nulls=>[],
:lengths=>{},
:externs=>[],
:length=>6},
:next=>112,
:type=>:secondary,
:key=>[{:name=>"c1", :type=>"INT UNSIGNED", :value=>1536700825}],
:row=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>361382}],
:sys=>[],
:length=>8}



指定c1的值为 1531865685、1536700825 执行查询,查看slow log,确认都需要扫描3个page,而如果换成介于这两个值之间的数据,则只需要扫描2个page。

InnoDB_pages_distinct: 3
...
select id, c1 from t_sk where c1 = 1531865685;

InnoDB_pages_distinct: 3
...
select id, c1 from t_sk where c1 = 1536700825;

InnoDB_pages_distinct: 2
...
select id, c1 from t_sk where c1 = 1536630003;

InnoDB_pages_distinct: 2
...
select id, c1 from t_sk where c1 = 1536575377;



这是因为辅助索引是非唯一的,即便是在等值查询时,也需要再读取下一条记录,以确认已获取所有符合条件的数据。

还有,当利用辅助索引读取数据时,如果要读取整行数据,则需要回表。

也就是说,除了扫描辅助索引数据页之外,还需要扫描聚集索引数据页。

来个例子看看就知道了。

#无需回表时
InnoDB_pages_distinct: 2
...
select id, c1 from tnull where c1 = 1536630003;

#需要回表时
InnoDB_pages_distinct: 5
...
select * from t_sk where c1 = 1536630003;

需要回表时,除了扫描辅助索引页2个page外,还需要回表扫描聚集索引页,而聚集索引是个3层树,因此总共需要扫描5个page。


            </div>
相关文章
|
前端开发 JavaScript 开发者
Vite前端构建工具详解
Vite 是一款新兴的前端构建工具,它的出现带来了前端开发体验的革命性变化。本文将介绍 Vite 的基本概念和核心特性,并通过代码实例来演示其强大功能。
428 0
|
存储 对象存储 UED
CDN适用哪些场景?
CDN是将源站内容分发至最接近用户的节点,使用户可就近取得所需内容,提高用户访问的响应速度和成功率。今天为大家分享几个CDN的典型适用场景。
16757 0
|
10月前
|
XML Java 数据格式
Spring容器的本质
本文主要讨论Spring容器最核心的机制,用最少的代码讲清楚Spring容器的本质。
|
安全 量子技术 数据安全/隐私保护
解密未来:量子加密技术在信息安全领域的革新展望
【10月更文挑战第28天】信息安全是现代社会的重要组成部分,量子加密技术作为新兴手段,利用量子力学原理,为信息安全带来革命性变革。本文介绍量子密钥分发(QKD)的基本原理,并通过代码示例展示其实际应用潜力。量子加密具有无条件安全、抗量子计算攻击等优势,未来有望成为保护信息安全的重要工具。
571 6
|
人工智能 自然语言处理 物联网
智能体进化发展了一年,现在的RPA Agent迭代到什么程度了?
智能体技术在过去一年迅速发展,RPA Agent已成为连接多种应用系统的关键工具。实在智能推出的实在Agent 7.0,通过自然语言处理和屏幕识别技术,实现了从需求输入到任务执行的全流程自动化,大幅降低了智能体构建门槛。该平台不仅能在企业级应用中提供专业服务,还能满足个人用户的多样化需求,真正实现了端到端的自动化解决方案。
439 6
智能体进化发展了一年,现在的RPA Agent迭代到什么程度了?
|
人工智能 弹性计算 自然语言处理
体验Comfyui后迷上了GenAI
《触手可及,函数计算玩转 AI 大模型》解决方案通过阿里云函数计算的无服务器架构,详细介绍了从选择模型模板到部署和调用的全过程。描述清晰,涵盖技术架构、部署步骤和示例代码,适合初学者。建议增加更多场景介绍(有时候用户不知道怎么变现)、常见问题解答和视频教程,以进一步提升用户体验。部署过程中未遇异常,函数计算的按需付费和弹性伸缩优势明显,适用于多种业务场景。建议提供更多性能优化、实际案例和安全合规建议。
291 0
|
人工智能 Python
蓝桥杯练习题(四):Python组之历届试题三十题
关于蓝桥杯Python组历届试题的三十个练习题的总结,包括题目描述、输入输出格式、样例输入输出以及部分题目的解题思路和代码实现。
513 0
蓝桥杯练习题(四):Python组之历届试题三十题
|
机器学习/深度学习 计算机视觉 UED
前向传播
【9月更文挑战第15天】
408 4
|
资源调度 数据中心 网络虚拟化
掌握这9个术语,轻松搞定VXLAN!
【10月更文挑战第27天】
461 3
掌握这9个术语,轻松搞定VXLAN!
|
编译器
R 语言教程 之 R 注释
R语言中的注释仅支持单行注释,使用#符号。多行注释可通过每行添加#或使用if(FALSE){}结构实现。注释帮助理解代码,但不参与执行。示例包括简单的打印语句和两数相加。
436 4