mysql存储数据，varchar类型中的数据变成了科学计数法？

最新推荐文章于 2024-04-21 22:10:35 发布

铁柱同学

最新推荐文章于 2024-04-21 22:10:35 发布

阅读量1w

点赞数 1

分类专栏： mysql 文章标签： mysql 科学计数法数据结构

本文链接：https://blog.csdn.net/ljfphp/article/details/108786014

版权

mysql 专栏收录该内容

61 篇文章 23 订阅

订阅专栏

博客讲述了在MySQL中使用varchar类型存储大数时，由于pow函数导致数值变为科学计数法的问题。作者通过排查确认是函数计算结果超出varchar范围所致。解决方案包括将数据类型改为bigint和使用按位或操作避免科学计数法存储。

摘要由CSDN通过智能技术生成

文章目录

一、前言

这个问题也是比较奇怪的，明明设置的是varchar类型，但存储的结果却是科学计数法，这还了得，必须找一下原因了

1、表现形式

            [uuid] => 1460444056320623751784
            [log_time] => 2016-05-30 01:03:01
            [daily_nums] => 1.125899906842624e15

就是这个daily_nums字段，十分的奇怪。

2、出现错误的sql

update test set daily_nums_nums =pow(2，x) where 1 ；

此处的pow函数是求幂次方的，博主这里是求2的n次方。，对了，mysql版本是5.7

二、问题排查

1、数据表结构

       $sql = "CREATE TEMPORARY TABLE if not exists test (
            uuid varchar(32) NOT NULL PRIMARY KEY,
            `log_time` datetime NOT NULL ,
            `daily_nums` VARCHAR(100) NOT NULL DEFAULT '0',
            UNIQUE KEY `uuid` (`uuid`),
            KEY (log_time)
        ) DEFAULT CHARSET utf8 COLLATE utf8_general_ci";

这里给出的是varchar(100)类型，没道理存不下小小十几位的数据才对，怪哉怪哉

2、错误推测

明明是varchar结果，为什么反而成大数了了呢，推测是两个可能

(1)数据库读出来是科学计数法
(2)数据库里面存储的就是科学计数法

答案是第二种

3、最终原因

此处应该是由于pow()这个函数的原因导致的，当2^50的时候，已经达到了15位，当51次方的时候，超过了15位，就记成了科学技术法

	2^ 50  = 562949953421312
	2^ 51 =  1.125899906842624e15

猜测也是有内部的数据结构导致的，类似于浮点型的精度问题，但是没找到具体的答案，这里不再深究。

参考php的14位大数转化为科学计数法：php使用位运算来实现日留存的算法

三、解决方案

1、更改数据结构

更改字段为bigint即可，下面可以测试下，当插入科学计数法的时候，bigint和varchar的区别：

（1）表结构

		CREATE TABLE `temp_drr_test` (
  `uuid` varchar(32) NOT NULL,
  `daily_nums` bigint(20) NOT NULL DEFAULT '0',
  `weekly_nums` bigint(20) NOT NULL DEFAULT '0',
  `monthly_nums` bigint(20) NOT NULL DEFAULT '0',
  `test_nums` varchar(100) DEFAULT '',
  UNIQUE KEY `uuid` (`uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

daily_nums为bigint， test_nums为varchar

（2）分别更新两个字段为科学计数法：2.251799813685248e15

	mysql> select * from temp_drr_test;
+------+---------------------+---------------------+--------------+---------------------+
| uuid | daily_nums          | weekly_nums         | monthly_nums | test_nums           |
+------+---------------------+---------------------+--------------+---------------------+
| 1111 | 4611686018427387904 | 9223372036854775807 |            0 | 4611686018427387904 |
+------+---------------------+---------------------+--------------+---------------------+
1 row in set (0.00 sec)

mysql> update temp_drr_test set daily_nums=2.251799813685248e15;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from temp_drr_test;
+------+------------------+---------------------+--------------+---------------------+
| uuid | daily_nums       | weekly_nums         | monthly_nums | test_nums           |
+------+------------------+---------------------+--------------+---------------------+
| 1111 | 2251799813685248 | 9223372036854775807 |            0 | 4611686018427387904 |
+------+------------------+---------------------+--------------+---------------------+
1 row in set (0.00 sec)

mysql> update temp_drr_test set test_nums=2.251799813685248e15;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from temp_drr_test;
+------+------------------+---------------------+--------------+----------------------+
| uuid | daily_nums       | weekly_nums         | monthly_nums | test_nums            |
+------+------------------+---------------------+--------------+----------------------+
| 1111 | 2251799813685248 | 9223372036854775807 |            0 | 2.251799813685248e15 |
+------+------------------+---------------------+--------------+----------------------+
1 row in set (0.00 sec)

最终发现，当字段为bigint的时候，是可以自动调节为数字的。只不过bigint能存储的长度也有限，难保不会超过，所以用下一个方法

2、按位或上一个值

update test set daily_nums =pow(2,x) | 0

这里选择0，这样在保证值不变的情况下，也能正常存储了，经测试无误，可以存储为大数。

end