当前位置: 首页 > 编程笔记 >

MySQL中浮点型转字符型可能会遇的问题详解

施敏达
2023-03-14
本文向大家介绍MySQL中浮点型转字符型可能会遇的问题详解,包括了MySQL中浮点型转字符型可能会遇的问题详解的使用技巧和注意事项,需要的朋友参考一下

前言

本文主要给大家介绍了MySQL中在将浮点型转字符型的时候遇到的一个问题,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧。

一 问题描述

今天遇到一个刷数据的需求,是修改产品的重量(字段类型为float),修改了产品的重量之后,是需要记录到日志表中的(字段类型为varchar),表结构如下:

临时刷数据表:

CREATE TABLE `temp_170830` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
 `goods_sn` varchar(255) NOT NULL DEFAULT '' COMMENT '产品编码',
 `goods_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '产品重量',
 `actual_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '实际重量',
 `new_actual_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '新的实际重量',
 `create_user` varchar(30) NOT NULL DEFAULT '' COMMENT '创建人',
 PRIMARY KEY (`id`),
 KEY `idx_goods_sn` (`goods_sn`)
) ENGINE=InnoDB AUTO_INCREMENT=8192 DEFAULT CHARSET=utf8 COMMENT='临时刷重量表';

日志表:

CREATE TABLE `log_weight` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
 `goods_sn` varchar(50) NOT NULL DEFAULT '' COMMENT '产品编码',
 `which_col` varchar(100) NOT NULL DEFAULT '' COMMENT '修改字段',
 `old_value` varchar(50) NOT NULL DEFAULT '0.00' COMMENT '更新前值',
 `new_value` varchar(50) NOT NULL DEFAULT '0.00' COMMENT '更新后值',
 `update_user` varchar(100) NOT NULL DEFAULT '' COMMENT '创建人',
 `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 `wh_update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录修改时间',
 PRIMARY KEY (`id`),
 KEY `idx_goods_sn` (`goods_sn`),
 KEY `idx_update_user` (`update_user`),
 KEY `wh_update_time` (`wh_update_time`)
) ENGINE=InnoDB AUTO_INCREMENT=14601620 DEFAULT CHARSET=utf8 COMMENT='重量修改日志';

如上面建的表所示,我需要将temp_170830表的actual_weight和new_actual_weight字段分别刷入log_weight表的old_value和new_value字段,SQL语句如下:

INSERT INTO log_weight(goods_sn, which_col, old_value, new_value, update_user)
SELECT goods_sn,'actual_weight',actual_weight,new_actual_weight,create_user FROM temp_170830;

本来以为到这里就已经大功告成了,毕竟只是插入一些日志记录,后来为了简单的进行核对,发现数据有些不对劲,如下图所示:

临时表数据截图:

日志表数据截图:

对比可以发现,插入的日志记录数据无缘无故后面多了很多位的小数,不知道从哪里冒出来的,后来一想,可能是本来浮点型的数据就是除不尽的,转成varchar的时候就把后面的那些也给带出来了,暂时也不是很确定,后续确定之后再补充,然后自己临时找了一个转varchar的方法concat,调整如下:

INSERT INTO log_weight(goods_sn, which_col, old_value, new_value, update_user)
SELECT goods_sn,'actual_weight',concat(actual_weight,''),concat(new_actual_weight,''),create_user FROM temp_170830;

顺利解决日志记录问题。

总结如下:

1 在记录价格和重量数字字段的时候,尽量不要使用浮点型!!!,浮点数坑多(比如浮点型是不能判断相等的!!!),最好是采用int整型,业务上要显示小数时,读取出来再除以相应的位数,比如99.98元,应存储9998,读取出来时,用9998/100来显示。

2 在float转varchar时,应该先把float用concat函数先转成varchar,再存储入varchar字段。

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对小牛知识库的支持。

 类似资料:
  • 问题内容: 我在MySQL数据库架构中引入浮点列时遇到了一个问题,即对浮点值的比较不会总是返回正确的结果。 1-50.12 2-34.57 3-12.75 4-…(其余均小于12.00) 这将返回“ 3”。 我已经读过,在MySQL中比较浮点值是一个坏主意,十进制类型是更好的选择。 我是否有希望继续使用float类型,并使比较正常工作? 问题答案: 您是否注意到以下问题? 在某些行之间有一个额外的

  • 问题内容: 给出的是一个简单的CSV文件: 显然,实际数据集比这要复杂得多,但是这一数据再现了错误。我正在尝试为其构建一个随机森林分类器,如下所示: 但是当我调用fit()时,我只是得到了这个追溯: scikit-learn版本为0.16.1。 问题答案: 在使用fit之前,您必须进行一些编码。如前所述,fit()不接受字符串,但是您可以解决此问题。 有几种可以使用的类: LabelEncoder

  • 2. 浮点型 C标准规定的浮点型有float、double、long double,和整型一样,既没有规定每种类型占多少字节,也没有规定采用哪种表示形式。浮点数的实现在各种平台上差异很大,有的处理器有浮点运算单元(FPU,Floating Point Unit),称为硬浮点(Hard-float)实现;有的处理器没有浮点运算单元,只能做整数运算,需要用整数运算来模拟浮点运算,称为软浮点(Soft-

  • 为什么当我尝试编译以下代码时会收到此错误消息? 或 不兼容的类型:从double到float的可能有损转换 我溢出来了吗?我想了解这背后的理论。提前感谢。

  • 本文向大家介绍详解Swift中的Characters字符类型与String字符串类型,包括了详解Swift中的Characters字符类型与String字符串类型的使用技巧和注意事项,需要的朋友参考一下 一、引言 Swift中提供了String类型与Characters类型来处理字符串和字符数据,Swift中的String类型除了提供了许多方便开发者使用的方法外,还可以与Foundation框架的

  • 本文向大家介绍浅谈python 读excel数值为浮点型的问题,包括了浅谈python 读excel数值为浮点型的问题的使用技巧和注意事项,需要的朋友参考一下 如下所示: 以上这篇浅谈python 读excel数值为浮点型的问题就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持呐喊教程。