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>
相关文章
|
人工智能 自然语言处理 自动驾驶
什么是人工智能
一、什么是人工智能 人工智能(Artificial Intelligence,简称AI)是指通过模拟人类智能思维和行为的方式,使机器能够像人类一样感知、理解、推理、学习和决策的一种技术和应用领域。它可以让计算机系统具有自主学习、自主决策、自主执行任务的能力,从而实现自动化、智能化的目标。常见的人工智能应用包括语音识别、图像识别、自然语言处理、机器翻译、智能推荐、自动驾驶等。 二、人工智能具有以下几个特点 1. 学习能力:人工智能系统可以通过学习从大量的数据中提取模式和规律,并根据学习到的知识和经验不断优化自身的性能。 2. 推理能力:人工智能系统可以根据已有的知识和规则进行推理,从而做出合理的
1791 0
|
5月前
|
数据采集 测试技术 API
小白必看!电商 API 开发避坑指南:签名错误、权限申请全解决
本文总结电商API开发常见问题与解决方案,涵盖京东、淘宝、拼多多的签名规则、权限申请、频率限制等核心踩坑点,结合实战案例,助你高效避坑,提升开发效率90%。
|
传感器 自动驾驶 算法
SLAM:SLAM(即时定位与地图构建)的简介、发展、案例应用之详细攻略
SLAM:SLAM(即时定位与地图构建)的简介、发展、案例应用之详细攻略
|
5月前
|
JSON 监控 算法
淘宝 + 京东关键字搜索比价 API 接口详解
本项目整合淘宝和京东商品搜索与比价API,支持跨平台价格对比、商品匹配、价格走势分析等功能。提供消费者最优价格选择,辅助商家市场调研与定价策略,附完整Python实现及应用解析。
|
人工智能 JSON 前端开发
copy和strong的区别及使用不当引起的crash
copy和strong的区别及使用不当引起的crash
304 0
|
设计模式 存储 缓存
12.享元模式设计思想
享元模式是一种用于性能优化的设计模式,通过共享相同或相似对象来减少内存占用。本文档详细介绍了享元模式的基础概念、实现原理、应用场景及优缺点,并通过具体例子如Integer、String、线程池和Handler等展示了其实际应用。此外,还探讨了享元模式与其他设计模式的结合使用,以及在休闲棋类和文本编辑器中的应用。适合需要优化系统性能和资源利用率的开发者参考。
222 2
|
人工智能 自然语言处理 语音技术
通用大模型VS垂直大模型
【7月更文挑战第16天】通用大模型VS垂直大模型
|
Java
java通过idea启动查看类加载来源信息
java通过idea启动查看类加载来源信息
427 0
|
Android开发 开发者
关于将Android AAB转化为APK
本篇文章主要讲如何将AAB转化为APK,虽然说我们上传到Google Play的AAB,是有Google Play自己去转化为APK给用户下载的,但是作为开发者的我们,也是需要知道应该如何转化的,毕竟我们还是要做测试的,当你拿到一个AAB文件的时候,你得知道如何将它转化成APK,然后安装在手机上,测试需要测试的内容。
1935 1
|
机器学习/深度学习
探索Transformer在金融行情预测领域的应用——预测银行间回购市场加权价格
文章先发在公众号上来,顺便在这里也写一下,主要思路其实就是模仿盘古天气大模型的方法,来试试能不能用来预测全国银行间市场质押式回购每日的加权平均价格,目前模型主要架构和训练粗略的跑了出来,效果不是太好,目前看了点其他paper,希望尝试利用已经开源的各种大模型做微调。欢迎大家批评指正。
探索Transformer在金融行情预测领域的应用——预测银行间回购市场加权价格