❶ 關於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、完成後保存數據 具體操作圖片如下 最總得出結論有長度，小數點設置所以可以設置類型長度。