没有合适的资源?快使用搜索试试~ 我知道了~
为什么不建议给MySQL设置Null值?《死磕MySQL系列 十八》.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 162 浏览量
2022-07-08
11:05:09
上传
评论
收藏 6.22MB DOC 举报
温馨提示
试读
11页
为什么不建议给MySQL设置Null值?《死磕MySQL系列 十八》.doc
资源推荐
资源详情
资源评论
为什么不建议给 MySQL 设置 Null 值?《死磕 MySQL 系列 十八》
大家好,我是咔咔 不期速成,日拱一卒
之前 ElasticSearch 系列文章中提到了如何处理空值,若为 Null 则会直接报错,因为在
ElasticSearch 中当字段值为 null 时、空数组、null 值数组时,会将其视为该字段没有值,最
终还是需要使用 exists 或者 null_value 来处理空值
大多数 ElasticSearch 的数据都来自于各类数据库,这里暂且只针对于 MySQL,各个开源
软件中都默认兼容各种 Null 值,空数组等等
若从根源上截断就可以省很多事,直到现在很多开发小伙伴还是坚韧不拔的给字段的默认
值还是 Null
本期就来聊一聊为什么不建议给字段的默认值设置为 Null
本期环境为:MySQL8.0.26
null
一、案例数据
创建表 user
CREATETABLE`user`(
`id`int(11)unsignedNOTNULLAUTO_INCREMENT,
`name`varchar(255)CHARACTERSETutf8mb4COLLATEutf8mb4_general_ciDEFAULTNULL,
`age`tinyint(4)unsignedNOTNULL,
PRIMARYKEY(`id`)
)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4COLLATE=utf8mb4_general_ci
添加数据,共计 10 条数据,有两条数据的 name 值为 Null
INSERTINTO`user`(`name`,`age`)VALUES(‘kaka’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘niuniu’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘yangyang’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘dandan’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘liuliu’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘yanyan’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘leilie’,26);
INSERTINTO`user`(`name`,`age`)VALUES(‘yao’,26);
INSERTINTO`user`(`name`,`age`)VALUES(NULL,26);
INSERTINTO`user`(`name`,`age`)VALUES(NULL,26);
一、count 数据丢失
在这期 MySQL 统计总数就用 count,别花里胡哨的《死磕 MySQL 系列 十》 文章中,
已经对 count 的使用说的非常明白了。
那借着这个案例,来分析一下为什么数据会丢失,先看结果
selectcount(*)asnum1,count(name)asnum2fromuser;
使用 count 字段名时出现了数据丢失,很明显是因为主键 ID9、10 这两条记录的 name 值
为空造成的。
为什么会出现这种情况?
当 count 除了主键字段外,会有两种情况:
一种是字段为 null,执行时,判断到有可能是 null,但还要把值取出来再判断下,不是 null
的进行累加
另一种是字段为 not null,执行时,逐行从记录里边读出这个字段,判断不是 null,才进
行累加
此时,咱们遇到的问题是 name 字段的值存在了 null 值,所以会走第一种情况,不进行统
计 null 值
为什么建议大家都使用 count(*)?
MySQL 对于 count 做了专门的优化,跟字段不同的是并不是把所有带了*的值取出来,而
是指定了 count(*)肯定不是 null,只需要按行累加即可
MySQL 团队对 count(*)做了什么优化?
MySQL 系列文章至今已经更新了第十八期了,你有没有猜到原因呢?
现在你应该知道主键索引结构中叶子节点存储的是整行数据,而普通索引叶子节点存储的
是主键 ID
那对于普通索引来说肯定会比主键索引小,因为对于 MySQL 来说,不管遍历哪个索引结
果都一样,所以优化器会主动去找到那颗最小的树进行遍历。
在逻辑正确的前提下,尽量减少访问数据量,是数据库系统设计通用法则之一。
最后给大家留一个问题,为什么 Innodb 存储引擎不跟 Myisam 存储一样存储一个 count 值
呢?
如果不知道的话,可以看上文提到的 count 文章
二、为 distinct 打抱不平
在开发工作中使用 Distinct 进行去重的场景十分的少,大多数情况都是使用 group by 完成
的
selectdistinctnamefromuser;
可以看到此时的数据依然是正确的,对 Null 值做了去重的操作
剩余10页未读,继续阅读
资源评论
书博教育
- 粉丝: 1
- 资源: 2837
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功