当 SQL Server(mssql-jdbc) 遇上 BigDecimal → 精度丢失,真坑!

sql,server,mssql,jdbc,遇上,bigdecimal,精度,丢失 · 浏览次数 : 1483

小编点评

## 问题解决总结 **问题:** * 如何处理 BigDecimal 数据类型中精度不一致的插入? **解决方案:** 1. **升级 mssql-jdbc 版本至 12.2.0 。** 2. **如果版本升级失败,尝试使用 BigDecimal 类型的特殊处理方式。** 3. **如果特殊处理方式无法解决问题,请向官方提交问题。** **其他提示:** * 在升级过程中,请注意版本兼容性。 * 在使用特殊处理方式之前,请仔细测试其效果。 * 关注 BigDecimal 数据类型中精度不一致的问题,并及时解决。

正文

开心一刻

  中午和哥们一起喝茶

  哥们说道:晚上喝酒去啊

  我:不去,我女朋友过生日

  哥们瞪大眼睛看着我:你有病吧,充气的过什么生日

  我生气到:有特么生产日期的好吧

需求背景

  系统对接了外部系统,调用外部系统的接口需要付费,一个接口一次调用付费 0.03 元

  同一个月内,同一个接口最高付费 25 元

  统计每个月的付费情况

  需求清楚了不?不清楚? 给大家举个案例

  这下明白了吧

  明白了需求,相信大家都会觉得很简单,不就是一个分组汇总吗?

  客官说的对,但生活总会给我们一点 surprise 

  我们慢慢往下看

环境准备

   SQL Server 版本: SQL Server 2017 

   MySQL 版本: 8.0.27 

  引入 MySQL ,是为了跟 SQL Server 做对比

   SQL Server 建表并初始化数据

CREATE TABLE tbl_interface_call_times (
    id BIGINT PRIMARY KEY IDENTITY(1,1),
    call_month INT NOT NULL,
        interface varchar(50) NOT NULL ,
        times INT NOT NULL
);
INSERT INTO tbl_interface_call_times(call_month, interface, times) VALUES
(202301, 'interface1', 800),
(202301, 'interface2', 1000),
(202301, 'interface3', 100),
(202302, 'interface1', 833),
(202302, 'interface2', 834),
(202302, 'interface3', 134),
(202302, 'interface4', 243),
(202302, 'interface5', 2143);
View Code

   MySQL 建表并初始化数据

CREATE TABLE tbl_interface_call_times (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    call_month INT NOT NULL COMMENT '月份',
        interface varchar(50) NOT NULL COMMENT '接口',
        times INT NOT NULL COMMENT '调用次数',
    PRIMARY KEY(id)
) COMMENT '接口调用次数';
INSERT INTO tbl_interface_call_times(call_month, interface, times) VALUES
(202301, 'interface1', 800),
(202301, 'interface2', 1000),
(202301, 'interface3', 100),
(202302, 'interface1', 833),
(202302, 'interface2', 834),
(202302, 'interface3', 134),
(202302, 'interface4', 243),
(202302, 'interface5', 2143);
View Code

  汇总每个月的付费, SQL 该如何写?

  很简单的啦,如下所示

SELECT call_month, 
    SUM(
        CASE WHEN times * 0.03 > 25 THEN 25
        ELSE times * 0.03
        END
    ) monthFee
FROM tbl_interface_call_times
GROUP BY call_month
View Code

  通用写法, SQL Server 和 MySQL 都支持

  我们看下查询结果

  一切都很正常,觉得世界真美好!

问题复现

  我们不能光玩数据库吧?

  不得像这样雨露均沾?

  必须把 spring-boot 、 MyBatis-Plus 安排上

   mysql-jdbc 版本: 8.0.21 , mssql-jdbc 版本: 6.2.1.jre8 

  完整代码:mybatis-plus-dynamic-datasource

  访问: http://localhost:8081/interface/summary?startMonth=202301&endMonth=202302 

  你会发现,你心心念念的 surprise 终于出现了!

  正确应该是 86.3.3 哪去了?

  直查数据库是没问题的呀

  莫非 MyBatis-Plus 有问题?

  我们切到 MySQL 试试;将 InterfaceCallTimesServiceImpl 上的数据源改成 mysql_db 

  然后重启,我们再访问: http://localhost:8081/interface/summary?startMonth=202301&endMonth=202302 

  这说明应该不是 MyBatis 的问题,那不完犊子了?

问题解决

  是不是束手无策了? 也不是,我们可以 Bing 一下的嘛

  你会发现说的都是批量 insert 的时候, BigDecimal 有精度丢失

  单条插入的时候,是没有精度丢失的

  然后了,大家试出了一条件论: 批量插入数据时,如果插入的数据精度不统一,最终入库的数据精度统一按最低的精度入库 

  虽说我们只是查询,莫非也需要 精度统一 ?

  精度统一

  试试呗,反正又不要钱

  重启,神奇的事情发生了

  .3 它回来了! 相信此刻的你肯定有一种与知己久别重逢的激动

  问题貌似解决了,但说实话,这种处理方式你用的放心吗?

  升级 mssql-jdbc 版本

  我们好好捋一下,程序从 SQL Server 获取数据,经历了哪些环节?

  只有三个: MyBatis-Plus  ->  mssql-jdbc ->  SQL Server 

  前面我们已经排除了 SQL Server 和 MyBatis-Plus 

  那问题肯定就出在 mssql-jdbc 身上了

  问题又来了,该如何从 mssql-jdbc 上找问题了?

  开源的东西从它的官方找相关的 issue ,肯定不止我们遇到这样的问题,那么肯定有人会给官方提了 issue 

   issue 地址: https://github.com/microsoft/mssql-jdbc/issues 

  直接搜索 BigDecimal ,像这样

  回车之后,你会发现,原来你不是一个人在战斗

  那就去里面找呗,发现 #1489 跟我们的问题有点像,仔细去读,发现关联了 #1912

  读到 1912 的末尾,你会发现又关联了 #2051,我们去看看 2051

  那就是在这里修复了呀,那它关联的版本是哪个了?

  然后我们在回到我们搜索 BigDecimal 相关 issue 的时候,你会发现

   12.2.0 已经发布了

  如果觉得看英文的费劲,那就看中文的:Microsoft JDBC Driver for SQL Server 发行说明

  这总看得懂了吧

  那就将 mssql-jdbc 升级到 12.2.0 试试

  入参不用统一精度,结果也正确了!

  但是,又开始转折了,你以为 12.2.0 就高枕无忧了?

   BigDecimal 的问题都延续到 12.3.0 了

  此刻大家的心情是怎样的,请评论区留言

总结

  1、当 mssql-jdbc 遇上 BigDecimal ,两种处理方式

    1.1  BigDecimal 类型的入参全部统一成最高精度

    1.2 版本升级到 12.2.0 ,但还是有问题,需要考虑业务是否会触发 12.2.0 的 bug 

  2、  mssql-jdbc 的 BigDecimal 的问题从 2016 年就开始出现了,到了现在( 2023 )还存在问题,我真的想对官方说一句

与当 SQL Server(mssql-jdbc) 遇上 BigDecimal → 精度丢失,真坑!相似的内容:

当 SQL Server(mssql-jdbc) 遇上 BigDecimal → 精度丢失,真坑!

开心一刻 中午和哥们一起喝茶 哥们说道:晚上喝酒去啊 我:不去,我女朋友过生日 哥们瞪大眼睛看着我:你有病吧,充气的过什么生日 我生气到:有特么生产日期的好吧 需求背景 系统对接了外部系统,调用外部系统的接口需要付费,一个接口一次调用付费 0.03 元 同一个月内,同一个接口最高付费 25 元 统计

【解惑】介绍三大数据库的with语句的写法及使用场景

WITH 子句通常被称为 "Common Table Expressions"(CTE),俗称内存临时表,当使用 WITH 语句时,应注意具体的数据库版本和支持情况。以下是对 MySQL、Microsoft SQL Server(MSSQL)和 Oracle 数据库的 WITH 语句用法示例,以及在

【Azure 存储服务】Azure Storage Account 下的 Table 查询的性能调优

问题描述 Azure Storage Account 下的 Table 查询的性能调优? 问题解答 因为Azure Storage Table服务(表服务) 与常规的关系型数据库不一样(例如:MySQL, SQL Server等),他里面存储的实体(Entity,表示一条数据)不能通过添加索引来优化

Docker安装MS SQL Server并使用Navicat远程连接

MS SQL Server简介 Microsoft SQL Server(简称SQL Server)是由微软公司开发的关系数据库管理系统,它是一个功能强大、性能卓越的企业级数据库平台,用于存储和处理大型数据集、支持高效查询和分析等操作。SQL Server 支持广泛的应用程序开发接口(API),包括

[转帖]一文搞懂各种数据库SQL执行计划:MySQL、Oracle等

https://zhuanlan.zhihu.com/p/99331255 MySQL 执行计划 Oracle 执行计划 SQL Server 执行计划 PostgreSQL 执行计划 执行计划(execution plan,也叫查询计划或者解释计划)是数据库执行 SQL 语句的具体步骤,例如通过索

推荐一款 在线+离线数据 同步框架 Dotmim.Sync

移动智能应用可以分为在线模式、纯离线模式与“在线+离线”混合模式。在线模式下系统数据一般存储在服务器端的大中型数据库(如 SQL Server、Oracle、MySQL 等),移动应用依赖于稳定可靠的网络连接;纯离线模式下系统数据一般存储在移动终端的轻量级数据库(如 SQLite等),移动应用不需要

基于SqlSugar的开发框架循序渐进介绍(27)-- 基于MongoDB的数据库操作整合

SqlSugar的开发框架本身主要是基于常规关系型数据库设计的框架,支持多种数据库类型的接入,如SqlServer、MySQL、Oracle、PostgreSQL、SQLite等数据库,非关系型数据库的MongoDB数据库也可以作为扩展整合到开发框架里面,通过基类的继承关系很好的封装了相关的基础操作功能,极大的减少相关处理MongoDB的代码,并提供很好的开发效率。本篇随笔介绍如何在SqlSuga

[转帖]MAXDOP(max degree of parallelism)

https://www.cnblogs.com/jenneyblog/p/MAXDOP.html 概述 当 SQL Server 在具有多个微处理器或 CPU 的计算机上运行时,它将为每个并行计划执行检测最佳并行度(即运行一个语句所使用的处理器数)。您可以使用 max degree of paral

[转帖]max degree of parallelism 选项

https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms181007(v=sql.105)?redirectedfrom=MSDN 当 SQL Server 在具有多个微处理器或 CPU 的计算机上运行

SQLSERVER 的主键索引真的是物理有序吗?

一:背景 1. 讲故事 最近在看 SQL SERVER 2008 查询性能优化,书中说当一个表创建了聚集索引,那么表中的行会按照主键索引的顺序物理排列,这里有一个关键词叫:物理排列,如果不了解底层原理,真的会被忽悠过去,其实仔细想一想不可能实现严格的 物理排列 ,那对性能是非常大的损害,本篇我们就从