java中BigDecimal 的加减乘除和“+”“-”“*”“”有什么区别

BigDecimal用作商业计算的。

BigDecimal aDouble =new BigDecimal(1.22)     输出：1.2199999999999999733546474089962430298328399658203125

BigDecimal aString = new BigDecimal("1.22")   输出：1.22

以上两者输出结果是不一样的。

原因：

double的构造方法有不可预知性。

String的构造方法是固定的值。

所以如果类型是Double的话，而且需要精确计算，就用下面方法：

Double.toString(double)方法，可以先转为String，然后再用new BigDecimal("")构造方法。

注意：BigDecimal都是不可变的（immutable）的，在进行每一步运算时，都会产生一个新的对象，所以在做加减乘除运算时千万要保存 *** 作后的值

Demo测试

    public static final void main(String[] args) {

        BigDecimal aBigDecimal = new BigDecimal("1.1")

        BigDecimal bBigDecimal = new BigDecimal("2.0")

        

        BigDecimal subtract = bBigDecimal.subtract(aBigDecimal)

        System.out.println("使用BigDecimal进行相减计算:" + subtract.doubleValue())

        System.out.println("直接相减: " + (2.0 - 1.1))

结果:

使用BigDecimal进行相减计算:0.9

直接相减: 0.8999999999999999

Int类型转换为bigdecimal类型:先将int转为String,再通过BigDecimal的构造方法去创建 BigDecimal price = new BigDecimal(String str) Bigdecimal类型相加 BigDecimal newDeposit=price.add(oldDecimal) 扩充 add(BigDecimal)BigDecimal对象中的值相加，然后返回这个对象。 subtract(BigDecimal)BigDecimal对象中的值相减，然后返回这个对象。 multiply(BigDecimal)BigDecimal对象中的值相乘，然后返回这个对象。 divide(BigDecimal)BigDecimal对象中的值相除，然后返回这个对象。 toString()将BigDecimal对象的数值转换成字符串。 doubleValue()将BigDecimal对象中的值以双精度数返回。 floatValue()将BigDecimal对象中的值以单精度数返回。 longValue()将BigDecimal对象中的值以长整数返回。 intValue()将BigDecimal对象中的值以整数返回。

bigdecimal(p,d)：p表示多少位数，d表示有多少位表示小数

与钱相关，比如工资使用BigDecimal，不用使用float、double避免计算时的精度丢失

参考： https://www.cnblogs.com/owenma/p/7097602.html

float、double在存储为二进制时会出现精度丢失，导致进行二进制计算时出现不数据不准确

varchar记录的是字符的长度

使用char，由于时固定长度，在数据检索时，磁盘IO的次数要比varchar少(每个数据段需要当前数据段的长度和结束)

所以，在长度变化不大的情况下，使用char。

当varchar大于5000，使用text代替，并且另建一张表，避免影响其它字端的检索效率

参考： https://www.jianshu.com/p/a1aa86e17bf7

对于有主键或者唯一键冲突的情况下，replace会使用delete+insert执行。但是在row模式下，binlog记录的是update

因此有这么一种情况：在自增主键并且binlog是row模式，当发生唯一性冲突时，主从库的自增列会产生不一致，导致主从切换时，在新主库新增数据会出现主键冲突（自增列是小于最大id值的）

先来看下面一句sql

上面这一段sql存在的问题：

虽让fr_id有索引，查询时可以用到fr_id索引，但是由于查询了所有字段会导致回表，并且随机读严重，扫面更多的页，最终会使整体sql的执行性能不佳

如何优化呢？

使用延迟关联：第一步先利用覆盖索引查询id，再做关联查询

如何进一步优化？

根据业务场景，如果不需要支持跳页(即只支持翻页，解决深度分页问题)，可以考虑用如下进行优化

第一次查询

第二次查询

假设第一次查询的结果的最大fr_id为200，那么第二次查询的如下

使用翻页要考虑的问题时，字段一定要是单调自增的，不然在翻页的过程中会有漏数据

所以整体优化思路为(两种方案二选一)：

1、使用延迟关联，解决两个问题（1.使用覆盖索引 2.减少回表次数、避免随机读，提高性能）

2、根据业务场景，是否需要支持跳页查询？

Mysql在创建表的时候有如下限制：

1、如果单个字段大小大于65535byte，自动转化成text

2、单行大小不能大于65535byte，否则创建失败，不包括text、blob字段

同时在插入数据有如下限制：

限制单行的大小不能大于单行的字段个数*768byte，否则会出现行裂变（768的含义是：mysql会对存储大字段进行优化，对每个字段的前768byte存储在当前页，其余存储在溢出页中，保证一个数据页至少能存储两行数据）

https://blog.csdn.net/wwd0501/article/details/115384399

https://blog.csdn.net/weixin_39761880/article/details/113336491

https://blog.csdn.net/m0_37695902/article/details/117695623

---