mysql的浮点型在什么情况下会损失精度,求大神详解、、

mysql的浮点型在什么情况下会损失精度,求大神详解、、,第1张

谈谈个人理解,请带着怀疑和鉴别的角度去看待。

1 先理解下定点数

--定义:

指规定小数点位置固定不变。

--存储:

* 在数据库或计算机中存储时,整数部分和小数部分分别使用一定的字节来存储(理解为分别用两部分字节来存储两个整数),小数点是作为存储属性存储的(如作为列类型时,小数点位置存储在表的定义部分),而不占用数据的存储字节。

* 定点数使用多少字节来存放数据,依赖于该数指定的精度(精度即为该数的总数字位数),总数字位数为小于2则使用1字节,为5-9位时用4字节,为19-38位时使用16字节(大部分数据库支持的最大就是38位数字);

--举例:

numeric(2,1),精度为2,使用1个字节来存放,存放数据范围为[-9.9, 9.9];如存储2.3时,在数据库存储为00100011,而小数位置固定在第四位前,这是由定义列时指明的;

--说明:

定点数存储精确的数字,numeric(2,1)就只能[-9.9, 9.9]之间的数,存的不是近似数(因为两部分都作为整数存储);当你在numeric(2,1)中存储2.33时,实际发生了隐式转换,实际存储为9.3(注意这并不是近似);

2 再来理解浮点数

--定义:

指采用浮点数表达方式来表示数据,这种表达方式利用科学计数法来表达实数,即用一个尾数(Mantissa ),一个基数(Base),一个指数(Exponent)以及一个表示正负的符号来表达数据,比如 123.45 用十进制科学计数法可以表达为 1.2345 × 10^2,其中 1.2345 为尾数,10 为基数,2 为指数。称其为浮点数就是因为利用指数达到了浮动小数点的效果。

--存储:

浮点数一般是使用IEEE规定的方式,即 对于单精度浮点数用1bit来存储符号位(正负号),8bit来存储指数,23bit来存储尾数;而且要求尾数的整数部分为1(注意,指二进位格式的,如1.01001),而且是使用二进位来保存,即基数为2;

在大多数数据库或计算机中存储时,单精度使用4字节,双精度使用8字节保存;

--举例:

二进制的 1001.101(对应于十进制的 9.625)可以表达为 1.001101 × 2^3,存储时符号位+存储为0,指数3存储为00000011,尾数1.001101存储为0011010000..(总共23位,去掉了小数点前的1,IEEE就是这样要求的);

--近似的产生:

因为我们使用的是十进制数,而计算机要转换为对应的二进制形式,由于有限的2进制位数表示的小数值不能和十进制一一对应(换句话说,十进制小数转为二进制可能变为无限小数而导致不精确 ),如2^-1对应0.5,2^-2对应0.25,2^-3对应0.125,因此对于像十进制的0.4(小数的末尾一位数不为5的)则不能精确存储;

--因近似引起的问题:

create table t (a float, b float)insert into t values(0.11, 0.04), (0.04, 0.11)

select * from t查询时显示正常,实际底层存储时发生了近似(十进制转换为二进制),而显示时又发生了近似(二进制转换为十进制);

select sum(a) from t查询显示 0.14999999850988388 ,为什么不是0.15的原因也就不言而喻了。

这也就是浮点数在损失精度、计算和比较要格外注意的事项;

3 总结

定点数,能存储精确数字,但保存的数据范围受了严格限制,格式也比较僵硬(这既是好处,也是坏处);

浮点数,不能存储精确数字,在小数的末尾一位数不是5(一直乘2不能圆整)的情况下会发生存储的近似处理;但可存储的数据范围更大;

库建立好之后基本不动,和我们接触最频繁的是表. 建表就是声明字段的过程!

选择合适的类型[速度快 减少硬盘占用]

存储空间,还是存储范围有区别?

答案: 两者本质完全一样 ,只是在一些特殊情况下两者显示有区别(只是在显示的时候补全0的位数不一样)

实验

*zerofill 零填充(本字段同时即自动带有unsigned属性,因为负数不能零填充)

如 数字2在固定宽度4时 零填充 即为0002

M值是一个整数(固定宽度值),只有在字段有零填充zerofill属性时 规定M值才有意义!

M值只是 显示效果 ,不会影响实际数据值!

如M值为1,实际值255,一样会显示255

列可以声明默认值(推荐声明)

因为null无法和别的值比较

null = 0 返回null

null <>0 返回null

null只能用is或is not比较 null is null当然对的。

例子:

【浮点型】有误差,不稳定!定点数更精确。

实际测试数据

Float(M,D)

M精度(总位数,不包含点) 精度值M 影响 存储的 值的范围.

D标度(小数位) 小数点后有几位(mysql比较特殊,mssql/oracle都不能指定)

testcolumn float(5,2) unsigned 范围0到999.99

float(5,2)的范围-999.99到999.99

给float(5,2)这样的字段插入值在进位时有一些规矩:暂时没搞清楚,不是简单的四舍五入

插入值688.826实际是688.83 末尾6 进位

插入值688.825实际是688.83 末尾5 进位

插入值688.824实际是688.82 末尾4 舍去

插入值688.005实际是688.00

插入值688.015实际是688.01 末尾5 5前面是1 舍去

插入值688.025实际是688.02 末尾5 5前面是2 舍去

插入值688.035实际是688.03 末尾5 5前面是3 舍去

插入值688.045实际是688.04 末尾5 5前面是4 舍去

一般使用tinyint、char(1)、enum类型。

varchar(M)

M代表宽度 即可容纳的【字符数】 (并不是字节数) varchar占用的字节数与编码有关:

utf-8 一个汉字3字节 英文字母1字节

对于utf8mb4号称占用4字节但是并不绝对(在utf8可以覆盖到的范围则仍然占用3字节)

utf8mb4最有优势的应用场景:存储emoji表情

例子:

性能太差,不推荐

MySQL在5.6.4版本之后,TimeStamp和DateTime支持到微妙

一个例子:

以如下这张表为例

show privileges 命令可以查看全部权限

查询时从user->db->table_pirv->columns_pirv依次验证,如果通过则执行查询。

本课程涉及建表SQL

场景1:歌单按时间排序

场景2:统计云音乐创建歌单的用户

场景3-1:统计云音乐创建歌单的用户列表和每人创建歌单的数量。

场景3-2:统计云音乐创建歌单的用户列表和每人创建歌单的数量,并且只显示歌单数量排序大于等于2的用户

SQL进阶语法-like

场景4:查询一个月内创建歌单(从第6行开始显示10条记录)

场景5:对于未录入歌曲的歌单(trackcount = null),输出结果时歌曲数返回0.

连接的作用是用一个SQL语句把多个表中相互关联的数据查出来

场景6:查询收藏“老男孩”歌单的用户列表

子查询:内层查询的结果作为外层的比较条件。一般子查询都可以转换成连接,推荐使用连接。

场景7:查询出没有用户收藏的歌单

场景8:老板想看创建和收藏歌单的所有用户,查询play_list和play_fav两表中所有的userid

实例还是上节中的那些表

场景1:查询每张专辑总的点播次数和每首歌的平均点播次数。

场景2:查询全部歌曲中的最大的播放次数和最小的播放次数。

场景2续:查询播放次数最多的歌曲

count(*) 和 count(1) 基本一样,没有明显的性能差异。

count(*) 和 count(song_name) 差别在于 count(song_name) 会除去song_name is null的情况

场景3:显示每张专辑的歌曲列表

实例:查询一个月内userid为1,3,5的用户创建的歌单

学生表:

用于更正成绩的触发器:


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8603560.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-18
下一篇 2023-04-18

发表评论

登录后才能评论

评论列表(0条)

保存