在将MySQL中的float数据同步到Elasticsearch时遇到精度损失问题，表现为2.99变为2.990000009536743。经过排查，确定问题源头在于MySQL的float类型。解决方案是在同步过程中，将数据转换为decimal(8, 2)类型，从而避免精度问题。这种方法适用于已有大量数据且不宜更改表结构的情况。"
133355925,19687570,I2C总线时钟频率编程设定指南,"['单片机', '嵌入式硬件', '编程', '通信接口']
场景描述
之前将mysql数据同步到ES，采用的是如下的架构，打造的是千万级别的实时搜索系统
详情请看 https://blog.csdn.net/laoyang360/article/details/52227541#commentBox
最近运营突然找到我说有一个问题就是为什么数据库源表这种是
2.99肿么变成了这个2.990000009536743，出现了精度上面的一些问题。一开始我也是一脸懵逼，以为是ES的问题，但是一想好像不对，ES的数据类型就是浮点型，不可能是ES把2.99转换成2.990000009536743了。
于是就开始分析了。
出问题只可能是三个位置：ES、mysql、同步过程
上面首先就排除了ES的问题，然后是同步的过程，经过验证同步过程中是没有这种骚操作的。那就只可能是mysql的问题
但是特别奇怪的是通过SQL语句查询出来的数据是正常的呀。
于是查看了一下出现问题的字段类型，发现这个字段的类型居然是float(8, 2)，搞得我一脸懵逼，
因为
FLOAT类型用于表示近似数值数据类型。SQL标准 允许在关键字FLOAT后面的括号内选择用位指定精度(但不能为指数范围)。MySQL还支持可选的只用于确定存储大小的精度规定。0到23的精度对应 FLOAT列的4字节单精度。24到53的精度对应DOUBLE列的8字节双精度。单精度浮点数用4字节&#x
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
