❶ 关于mysql中DOUBLE和FLOAT类型的问题
就是因为看了<MySQL 3.23 中文参考手册>一文，所以设置了float(32,5)这样一个字段来测试float
float是用4个([1,24）)或者8个([24,53)）字节存储数据，
我设置了数据3647483999插入表中 结果得到3647483904.00000 ，修改任何小数部分也得到3647483904.00000 然而修改成3947483904.00000，3997483904.00000 却成功保存
我开始怀疑是不是mysql的float类型的数据的高位字节和低位字节之间的进位有问题啊？
后来发现应该是与科学记数法有关，不管你设置多少位小数，当整数部分超过512的时候 mysql总是以科学技术法的方式来保存数据....
不知道这个分析对不对？
❷ mysql中想要在已有的表中修改数据类型的长度，急~~~
sql语句说明：alter table 表名 modify column 字段 类型(长度);
alter table 销售表 modify column 数量 int;
alter table 销售表 modify column 金额 float(8);
❸ 在access中如何设置float类型的长度求帮助，急需！
在表设计器中，选中字段
数据类型选”数字“，在下面的字段大小中选“单精度”（single）即是浮点（带小数）类型
如要设置长度，在“小数位数”项下进行设置
❹ sql数据库中的Float数据类型是占几位,几个字节 ，也就是占几个0和1
sql数据库中的Float数据类型是占几位,几个字节 ，也就是占几个0和1
FLOAT数据类型可精确到第15位小数，其范围为从-1.79e-308到1.79e+308.每个float类型的数据占用8个字节的存储空间。 float数据类型可写为float([n])的形式。n指定Float数据的精度。n为1到15之间的整数值。当n取1到7时，实际上是定义了一个real类
❺ mysql往数据库插入float类型的数据 为什么数字不对
float类型可以存浮点数，但是float有缺点，当不指定小数位数的时候，就会出现小数位数与想要的不一致，导致“报错”。在创建浮点类型的时候必须指定小数位数，float(m,d)，m表示的是最大长度，d表示的显示的小数位数。
虽然两个类型的值有相似也有不相似，但定义的是float、插入的值只要不出错肯定是float类型，10表示该值一共显示10位整数，其中3位位于小数点后面。
(5)数据库设置float长度扩展阅读：
浮点包可以将二进制浮点数存储为非标准化数，而不使用刚刚介绍的存储方法。“非标准化数”是带有保留指数值的非零浮点数，其中尾数的最高有效位为 0。
通过使用非标准化格式，浮点数的范围可以扩展，但会失去精度。您无法控制浮点数以标准化形式还是非标准化形式表示；浮点包决定了表示形式。浮点包从不使用非标准化形式，除非指数变为小于可以标准化形式表示的最小值。
❻ 在插入数据到sql数据库时提示：将float转换为数据类型numeric时出现算术溢出错误,语句已终止
倒着看，多试试吧。不能把目标数据库的字段类型改成double吗？
---------------------------
decimal(numeric ) 同义，用于精确存储数值
decimal 数据类型最多可存储 38 个数字，所有数字都能够放到小数点的右边。decimal 数据类型存储了一个准确（精确）的数字表达法；不存储值的近似值。
定义 decimal 的列、变量和参数的两种特性如下：
p 小数点左边和右边数字之和，不包括小数点。如 123.45,则 p=5，s=2。
指定精度或对象能够控制的数字个数。
s
指定可放到小数点右边的小数位数或数字个数。
p 和 s 必须遵守以下规则：0 <= s <= p <= 38。
numeric 和 decimal 数据类型的默认最大精度值是 38。在 Transact-SQL 中，numeric 与 decimal 数据类型在功能上等效。
当数据值一定要按照指定精确存储时，可以用带有小数的 decimal 数据类型来存储数字。
转换 decimal 和 numeric 数据
对于 decimal 和 numeric 数据类型，Microsoft?? SQL Server?? 将精度和小数位数的每个特定组合看作是不同的数据类型。例如，decimal(5,5) 和 decimal(5,0) 被当作不同的数据类型。
在 Transact-SQL 语句中，带有小数点的常量自动转换为 numeric 数据值，且必然使用最小的精度和小数位数。例如，常量 12.345 被转换为 numeric 值，其精度为 5，小数位为 3。
从 decimal 或 numeric 向 float 或 real 转换会导致精度损失。从 int、smallint、tinyint、float、real、money 或 smallmoney 向 decimal 或 numeric 转换会导致溢出。
默认情况下，在将数字转换为较低精度和小数位数的 decimal 或 numeric 值时，SQL Server 使用舍入法。然而，如果 SET ARITHABORT 选项为 ON，当发生溢出时，SQL Server 会出现错误。若仅损失精度和小数位数，则不会产生错误。
❼ sql数据库中 一个字段存储的数据有可能是整数又有可能是小数,该怎么设置数据类型
(1)二进制数据类型
二进制数据包括 Binary、Varbinary 和 Image
Binary 数据类型既可以是固定长度的(Binary),也可以是变长度的。
Binary[(n)] 是 n 位固定的二进制数据。其中，n 的取值范围是从 1 到 8000。其存储窨的大小是 n + 4 个字节。
Varbinary[(n)] 是 n 位变长度的二进制数据。其中，n 的取值范围是从 1 到 8000。其存储窨的大小是 n + 4个字节，不是n 个字节。
在 Image 数据类型中存储的数据是以位字符串存储的，不是由 SQL Server 解释的，必须由应用程序来解释。例如，应用程序可以使用BMP、TIEF、GIF 和 JPEG 格式把数据存储在 Image 数据类型中。
(2)字符数据类型
字符数据的类型包括 Char，Varchar 和 Text
字符数据是由任何字母、符号和数字任意组合而成的数据。
Varchar 是变长字符数据，其长度不超过 8KB。Char 是定长字符数据，其长度最多为 8KB。超过 8KB 的ASCII 数据可以使用Text数据类型存储。例如，因为 Html 文档全部都是 ASCII 字符，并且在一般情况下长度超过 8KB，所以这些文档可以 Text 数据类型存储在SQL Server 中。
❽ 如何在ARCGIS中创建float字段类型且可以设置字段长度，小数位数
浮点型的字段长度只能为1~10，超过10自动回转换为double
数据类型精度（字段长度）范围（小数位数）如下：
短整型* 1–4 (Oracle); 1–5（SQL Server、PostgreSQL）; 5（DB2、Informix） 0
长整型 5–10 (Oracle)；6-10 (PostgreSQL)；6-9（DB2、Informix 和 SQL Server） 0
浮点型 1–6 1–6
双精度 7+ 0+
(8)数据库设置float长度扩展阅读：
短整型的二进制位长是16，长整型的是32位。就是说长整型可以表示位数更多的整数。短整型所能表示的整数的值域为-32768~32767。
长整型则为-2147483648~2147483647。例如，如果有个数为32780，那么它只能用长整型表示，而不能用短整型表示。
长整型是程序设计中数据类型的一种表现方式，通常用long 表示长整型，long 有符号64位整数 范围是-2^63-2^63 -1 Int64unsigned long 无符号64位整数 0-2^64-1 UInt64。
❾ mysql里float是什么东西
今天做实验，本来以前都已经做得差不多了的，可突然U盘一下子坏掉，计算机无法识别，驱动重装没用，别人机器上也不能使用，看来是U盘自身出问题了。而更可怕的是，最近忙着整理材料，所以许多最新版本的材料和学习工作方面的资料都在U盘中，并且其中的许多老版本自己机器上早已删掉，怪只怪我太信任这块盘了。没办法，实验得重做，资料可能也得重新写重新找了......
然后就在做第二个实验结尾后意外地发现了MySQL数据类型中float的一个问题，现在帖出来请大家指点。网络中许多同仁也遇到了这个问题－－传说中精典的浮点数精度问题。
原文如下：
一、浮点数的概念及误差问题：
浮点数是用来表示实数的一种方法，它用 M(尾数) * B( 基数)的E(指数）次方来表示实数，相对于定点数来说，在长度一定的情况下，具有表示数据范围大的特点。但同时也存在误差问题，这就是着名的浮点数精度问题！
浮点数有多种实现方法，计算机中浮点数的实现大都遵从 IEEE754 标准，IEEE754 规定了单精度浮点数和双精度浮点数两种规格，单精度浮点数用4字节（32bit）表示浮点数，格式是：
1位符号位 8位表示指数 23位表示尾数
双精度浮点数8字节（64bit）表示实数，格式是：
1位符号位 11位表示指数 52位表示尾数
同时，IEEE754标准还对尾数的格式做了规范：d.dddddd...，小数点左面只有1位且不能为零，计算机内部是二进制，因此，尾数小数点左面部分总是1。显然，这个1可以省去，以提高尾数的精度。由上可知，单精度浮点数的尾数是用24bit表示的，双精度浮点数的尾数是用53bit表示的，转换成十进制：
2^24 - 1 = 16777215 2^53 - 1 = 9007199254740991
由上可见，IEEE754单精度浮点数的有效数字二进制是24位，按十进制来说，是8位；双精度浮点数的有效数字二进制是53位，按十进制来说，是16 位。显然，如果一个实数的有效数字超过8位，用单精度浮点数来表示的话，就会产生误差！同样，如果一个实数的有效数字超过16位，用双精度浮点数来表示，也会产生误差！对于 1310720000000000000000.66 这个数，有效数字是24位，用单精度或双精度浮点数表示都会产生误差，只是程度不同：
单精度浮点数： 1310720040000000000000.00
双精度浮点数： 1310720000000000000000.00
双精度差了 0.66 ，单精度差了近4万亿！这个结果为什么与翟振兴例子中的差很多呢？原因是翟振兴的测试用表中对字段进行了限制，实际上显示的是mysql溢出后的值，而我这里给出的是计算机中实际的值，如果把测试表字段精度提高到24位或以上，得到的结果就相同了。
以上说明了因长度限制而造成的误差，但这还不是全部！采用IEEE754标准的计算机浮点数，在内部是用二进制表示的，但在将一个十进制数转换为二进制浮点数时，也会造成误差，原因是不是所有的数都能转换成有限长度的二进制数。对于翟振兴测试中用到的 131072.32 这个数，其有效数字是8位，按理应该能用单精度浮点数准确表示，为什么会出现偏差呢？看一下这个数据二进制尾数就明白了
10000000000000000001010001......
显然，其尾数超过了24bit，根据舍入规则，尾数只取 100000000000000000010100，结果就造成翟振兴测试中遇到的“奇怪”现象！131072.68 用单精度浮点数表示变成 131072.69 ，原因与此类似。实际上有效数字小于8位的数，浮点数也不一定能精确表示，7.22这个数的尾数就无法用24bit二进制表示，当然在数据库中测试不会有问题（舍入以后还是7.22），但如果参与一些计算，误差积累后，就可能产生较大的偏差。
二、mysql 和 oracle中的数值类型：
翟振兴发现的问题是不是只有 mysql 存在呢？显然不是，只要是符合IEEE754标准的浮点数实现，都存在相同的问题。
mysql中的数值类型（不包括整型）：
IEEE754浮点数： float （单精度） ， double 或 real （双精度）
定点数： decimal 或 numeric
oracle中的数值类型：
oracle 浮点数 ： number （注意不指定精度）
IEEE754浮点数： BINARY_FLOAT （单精度） ， BINARY_DOUBLE （双精度）
FLOAT，FLOAT(n) （ansi要求的数据类型）
定点数： number(p,s)
如果在oracle中，用BINARY_FLOAT等来做测试，结果是一样的。
因此，在数据库中，对于涉及货币或其他精度敏感的数据，应使用定点数来存储，对mysql来说是 decimal，对oracle来说就是number(p,s)。双精度浮点数，对于比较大的数据同样存在问题！
三、编程中也存在浮点数问题：
不光数据库中存在浮点数问题，编程中也同样存在，甚至可以说更值得引起注意！
通过上面的介绍，浮点数的误差问题应该比较清楚了。如果在程序中做复杂的浮点数运算，误差还会进一步放大。因此，在程序设计中，如果用到浮点数，一定要意识到可能产生的误差问题。不仅如此，浮点数如果处理不好，还会导致程序BUG！看下面的语句：
if (x != y) { z = 1 / (x -y);}
这个语句看起来没有问题，但如果是浮点数，就可能存在问题！再看下面的语句会输出什么结果：
public class Test {
public static void main(String[] args) throws Exception {
System.out.print("7.22-7.0=" + (7.22f-7.0f));
}
}
我们可能会想当然地认为输出结果应该是 0.22 ，实际结果却是 0.21999979 !
因此，在编程中应尽量避免做浮点数的比较，否则可能会导致一些潜在的问题！
除了这些，还应注意浮点数中的一些特殊值，如 NaN、+0、-0、+无穷、-无穷等，IEEE754虽然对此做了一些约定，但各具体实现、不同的硬件结构，也会有一些差异，如果不注意也会造成错误！
四、总结：
从上面的分析，我们可以得出以下结论：
1、浮点数存在误差问题；
2、对货币等对精度敏感的数据，应该用定点数表示或存储；
3、编程中，如果用到浮点数，要特别注意误差问题，并尽量避免做浮点数比较；
4、要注意浮点数中一些特殊值的处理。
June，浮点数问题，很容易被忽视，可能具有一定的普遍性，也许应该发给其他技术人员，以免再出现这方面的问题。
-----Original Message-----
From: htang [mailto:[email protected]]
Sent: Tuesday, September 26, 2006 6:29 PM
To: 翟振兴
Cc: LisaLan; 关宝军; 韦连友
Subject: RE: RE: mysql中float的问题
这个问题不是一个Bug，而是浮点数本身存在的局限。原因是计算机对浮点数的表示是 M * 2 的 N 次方，其中M是尾数，N是指数，在此转换过程中存在数据损失，因此浮点数（包括double类型）是不能精确表示所有实数的。出现的问题正是由误差和四舍五入造成的。
-----Original Message-----
From: 翟振兴 [mailto:[email protected]]
Sent: Tuesday, September 26, 2006 12:17 PM
To: htang
Cc: LisaLan; 关宝军; 韦连友
Subject: Re: RE: mysql中float的问题
Importance: High
老唐,您好！
昨天测试发现，当float数据类型超过131072时候，插入的数据会发现不稳定情况，测试过程如下：
mysql> desc test10;
+------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------+------+-----+---------+-------+
| floattest | float(12,2) | YES | | NULL | |
| doubletest | double(12,2) | YES | | NULL | |
| dectest | decimal(12,2) | YES | | NULL | |
+------------+---------------+------+-----+---------+-------+
mysql> insert into test10 values(131071,131071,131071);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
+-----------+------------+-----------+
1 row in set (0.00 sec)
mysql> insert into test10 values(131071.32,131071.32,131071.32);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
+-----------+------------+-----------+
2 rows in set (0.00 sec)
mysql> insert into test10 values(131071.68,131071.68,131071.68);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
+-----------+------------+-----------+
3 rows in set (0.01 sec)
mysql> insert into test10 values(131072,131072,131072);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
| 131072.00 | 131072.00 | 131072.00 |
+-----------+------------+-----------+
4 rows in set (0.00 sec)
mysql> insert into test10 values(131072.32,131072.32,131072.32);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
| 131072.00 | 131072.00 | 131072.00 |
| 131072.31 | 131072.32 | 131072.32 |
+-----------+------------+-----------+
5 rows in set (0.00 sec)
mysql> insert into test10 values(131072.68,131072.68,131072.68);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
| 131072.00 | 131072.00 | 131072.00 |
| 131072.31 | 131072.32 | 131072.32 |
| 131072.69 | 131072.68 | 131072.68 |
+-----------+------------+-----------+
6 rows in set (0.00 sec)
mysql> insert into test10 values(131072.66,131072.66,131072.66);
Query OK, 1 row affected (0.00 sec)
mysql> select * from test10;
+-----------+------------+-----------+
| floattest | doubletest | dectest |
+-----------+------------+-----------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
| 131072.00 | 131072.00 | 131072.00 |
| 131072.31 | 131072.32 | 131072.32 |
| 131072.69 | 131072.68 | 131072.68 |
| 131072.66 | 131072.66 | 131072.66 |
+-----------+------------+-----------+
mysql> insert into test10 values(1310720000000000000000.66,1310720000000000000000.66,1310720000000000000000.66);
Query OK, 1 row affected, 3 warnings (0.00 sec)
mysql> select * from test10;
+----------------+---------------+---------------+
| floattest | doubletest | dectest |
+----------------+---------------+---------------+
| 131071.00 | 131071.00 | 131071.00 |
| 131071.32 | 131071.32 | 131071.32 |
| 131071.68 | 131071.68 | 131071.68 |
| 131072.00 | 131072.00 | 131072.00 |
| 131072.31 | 131072.32 | 131072.32 |
| 131072.69 | 131072.68 | 131072.68 |
| 131072.66 | 131072.66 | 131072.66 |
| 10000000000.00 | 9999999999.99 | 9999999999.99 |
+----------------+---------------+---------------+
以上测试说明：
当insert的数据范围在＋－131072（65536×2）以内的时候，float数据精度是正确的，但是超出这个范围的数据就不稳定，没有发现有相关的参数设置
建议：将float改成double或者decimal，两者的差别是double是浮点计算，decimal是定点计算，会得到更精确的数据。
❿ Navicat for MySql怎么设置double和float型的小数长度
设置方法：
1、安装好Mysql后 下载navicat类似管理工具。
2、根据所需连接Mysql，新建数据库、表，根据字段设置长度。
3、完成后保存数据 具体操作图片如下 最总得出结论有长度，小数点设置所以可以设置类型长度。