mysql資料庫存儲類型
Mysql資料庫3種存儲（MyISAM、MEMORY、InnoDB）引擎區別：
1、Myisam是Mysql的默認存儲引擎，當create創建新表時，未指定新表的存儲引擎時，默認使用Myisam。MEMORY、InnoDB不是默認存儲引擎。
2、InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比Myisam的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。
Mysql資料庫3種存儲（MyISAM、MEMORY、InnoDB）區別對比：
1、MyISAM
它不支持事務，也不支持外鍵，尤其是訪問速度快，對事務完整性沒有要求或者以SELECT、INSERT為主的應用基本都可以使用這個引擎來創建表。
數據文件和索引文件可以放置在不同的目錄，平均分配IO，獲取更快的速度。要指定數據文件和索引文件的路徑，需要在創建表的時候通過DATA DIRECTORY和INDEX DIRECTORY語句指定，文件路徑需要使用絕對路徑。
2、MEMORY
memory使用存在內存中的內容來創建表。每個MEMORY表實際對應一個磁碟文件，格式是.frm。MEMORY類型的表訪問非常快，因為它到數據是放在內存中的，並且默認使用HASH索引，但是一旦伺服器關閉，表中的數據就會丟失，但表還會繼續存在。
默認情況下，memory數據表使用散列索引，利用這種索引進行「相等比較」非常快，但是對「范圍比較」的速度就慢多了。因此，散列索引值適合使用在"="和"<=>"的操作符中，不適合使用在"<"或">"操作符中，也同樣不適合用在order by字句里。如果確實要使用"<"或">"或betwen操作符，可以使用btree索引來加快速度。
存儲在MEMORY數據表裡的數據行使用的是長度不變的格式，因此加快處理速度，這意味著不能使用BLOB和TEXT這樣的長度可變的數據類型。VARCHAR是一種長度可變的類型，但因為它在MySQL內部當作長度固定不變的CHAR類型，所以可以使用。
3、InnoDB
InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比MyISAM的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。
（1)自動增長列：
InnoDB表的自動增長列可以手工插入，但是插入的如果是空或0，則實際插入到則是自動增長後到值。可以通過"ALTER TABLE...AUTO_INCREMENT=n;"語句強制設置自動增長值的起始值，默認為1，但是該強制到默認值是保存在內存中，資料庫重啟後該值將會丟失。
可以使用LAST_INSERT_ID()查詢當前線程最後插入記錄使用的值。如果一次插入多條記錄，那麼返回的是第一條記錄使用的自動增長值。對於InnoDB表，自動增長列必須是索引。如果是組合索引，也必須是組合索引的第一列，但是對於MyISAM表，自動增長列可以是組合索引的其他列，這樣插入記錄後，自動增長列是按照組合索引到前面幾列排序後遞增的。
（2）外鍵約束：
MySQL支持外鍵的存儲引擎只有InnoDB，在創建外鍵的時候，父表必須有對應的索引，子表在創建外鍵的時候也會自動創建對應的索引。
Ⅱ mysql 資料庫varchar可以存儲多少個漢字和多少個數字
首先要確定mysql版本，一般一個漢字2個位元組，50即可存25個漢字。
4.0版本以下，varchar(100)，指的是100位元組，如果存放UTF8漢字時，只能存33個（每個漢字3位元組）
5.0版本以上，varchar(100)，指的是100字元，無論存放的是數字、字母還是UTF8漢字（每個漢字3位元組），都可以存放100個。
varchar特點
1、使用比固定長度類型(char)佔用更少存儲空間(除了使用ROW_FORMAT=FIXED創建的MyISAM表)。
2、使用額外的1-2位元組來存儲值長度，列長度<=255使用1位元組保存，其它情況使用2位元組保存。例如varchar(10)會佔用11位元組存儲空間，varchar(500)會佔用502位元組存儲空間。
3、節約空間，所以性能會有幫助。在更新的時候會產生額外的工作。
以上內容參考：網路-varchar
Ⅲ MySQL里存儲圖片的是什麼數據類型
背景
MySQL 一直以來都有 TEXT、BLOB 等類型用來存儲圖片、視頻等大對象信息。比如一張圖片，隨便一張都 5M 以上。視頻也是，隨便一部視頻就是 2G 以上。
假設用 MySQL 來存放電影視頻等信息，一部是 2G，那麼存儲 1000 部就是 2TB，2TB 也就是 1000 條記錄而已，但是對資料庫性能來說，不僅僅是看記錄數量，更主要的還得看佔用磁碟空間大小。空間大了，所有以前的經驗啥的都失效了。
所以一般來說存放這類信息，也就是存儲他們的存放路徑，至於文件本身存放在哪裡，那這就不是資料庫考慮的范疇了。資料庫只關心怎麼來的快，怎麼來的小。
舉例
雖然不推薦 MySQL 這樣做，但是也得知道 MySQL 該怎麼做才行，做到心裡有數。比如下面一張微信圖片，大概 5M 的樣子。
root@ytt:/var/lib/mysql-files# ls -sihl 微信圖片_20190711095019.jpg274501 5.4M -rw-r--r-- 1 root root 5.4M Jul 11 07:17 微信圖片_20190711095019.jpg
拷貝 100 份這樣的圖片來測試
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`; do cp 微信圖片_20190711095019.jpg "$i".jpg;done;
root@ytt:/var/lib/mysql-files# ls
100.jpg 17.jpg 25.jpg 33.jpg 41.jpg 4.jpg 58.jpg 66.jpg 74.jpg 82.jpg 90.jpg 99.jpg f8.tsv
10.jpg 18.jpg 26.jpg 34.jpg 42.jpg 50.jpg 59.jpg 67.jpg 75.jpg 83.jpg 91.jpg 9.jpg 微信圖片_20190711095019.jpg
1111.jpg 19.jpg 27.jpg 35.jpg 43.jpg 51.jpg 5.jpg 68.jpg 76.jpg 84.jpg 92.jpg f1.tsv
11.jpg 1.jpg 28.jpg 36.jpg 44.jpg 52.jpg 60.jpg 69.jpg 77.jpg 85.jpg 93.jpg f2.tsv
12.jpg 20.jpg 29.jpg 37.jpg 45.jpg 53.jpg 61.jpg 6.jpg 78.jpg 86.jpg 94.jpg f3.tsv
13.jpg 21.jpg 2.jpg 38.jpg 46.jpg 54.jpg 62.jpg 70.jpg 79.jpg 87.jpg 95.jpg f4.tsv
14.jpg 22.jpg 30.jpg 39.jpg 47.jpg 55.jpg 63.jpg 71.jpg 7.jpg 88.jpg 96.jpg f5.tsv
15.jpg 23.jpg 31.jpg 3.jpg 48.jpg 56.jpg 64.jpg 72.jpg 80.jpg 89.jpg 97.jpg f6.tsv
16.jpg 24.jpg 32.jpg 40.jpg 49.jpg 57.jpg 65.jpg 73.jpg 81.jpg 8.jpg 98.jpg f7.tsv
mysql> show create table tt_image1G
*************************** 1. row ***************************
Table: tt_image1
Create Table: CREATE TABLE `tt_image1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longblob,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql> show create table tt_image2G
*************************** 1. row ***************************
Table: tt_image2
Create Table: CREATE TABLE `tt_image2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longtext,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql> show create table tt_image3G
*************************** 1. row ***************************
Table: tt_image3
Create Table: CREATE TABLE `tt_image3` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
tt_image1
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image1(image_file)
values (load_file('/var/lib/mysql-files/$i.jpg'))";done;
tt_image2
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image2(image_file)
values (hex(load_file('/var/lib/mysql-files/$i.jpg')))";done;
tt_image3
root@ytt:/var/lib/mysql-files# aa='begin;';for i in `seq 1 100`;
do aa=$aa"insert into ytt.tt_image3(image_file) values
('/var/lib/mysql-files/$i.jpg');";
done;aa=$aa'commit;';mysql -S /var/run/mysqld/mysqld.sock -e "`echo $aa`";
- mysql> select 'tt_image1' as name ,count(*) from tt_image1 union allselect 'tt_image2',count(*) from tt_image2 union all select 'tt_image3', count(*) from tt_image3;+-----------+----------+| name | count(*) |+-----------+----------+| tt_image1 | 100 || tt_image2 | 100 || tt_image3 | 100 |+-----------+----------+3 rows in set (0.00 sec)
- root@ytt:/var/lib/mysql/ytt# ls -silhS tt_image*274603 1.1G -rw-r----- 1 mysql mysql 1.1G Jul 11 07:27 tt_image2.ibd274602 545M -rw-r----- 1 mysql mysql 544M Jul 11 07:26 tt_image1.ibd274605 80K -rw-r----- 1 mysql mysql 112K Jul 11 07:27 tt_image3.ibd
- mysql> select * from tt_image3;+----+----------------------------+| id | image_file |+----+----------------------------+| 1 | /var/lib/mysql-files/1.jpg |+----+----------------------------+...100 rows in set (0.00 sec)
- mysql> DELIMITER $$mysql> USE `ytt`$$mysql> DROP PROCEDURE IF EXISTS `sp_get_image`$$mysql> CREATE DEFINER=`ytt`@`localhost` PROCEDURE `sp_get_image`()mysql> BEGIN DECLARE i,cnt INT DEFAULT 0; SELECT COUNT(*) FROM tt_image1 WHERE 1 INTO cnt; WHILE i < cnt DO SET @stmt = CONCAT('select image_file from tt_image1 limit ',i,',1 into mpfile ''/var/lib/mysql-files/image',i,'.jpg'''); PREPARE s1 FROM @stmt; EXECUTE s1; DROP PREPARE s1; SET i = i + 1; END WHILE; END$$mysql> DELIMITER ;mysql> call sp_get_image;
佔用磁碟空間大（這樣會帶來各種各樣的功能與性能問題，比如備份，寫入，讀取操作等）
使用不易
還是推薦用文件路徑來代替實際的文件內容存放
我們建三張表，分別用 LONGBLOB、LONGTEXT 和 VARCHAR 來存儲這些圖片信息
我們來給三張表插入 100 張圖片（插入前，建議把 max_allowed_packet 設置到最大）
檢查下三張表記錄數
看下文件大小，可以看到實際大小排名，LONGTEXT 欄位存儲的最大，LONGBLOB 欄位縮小到一半，最小的是存儲圖片路徑的表 tt_image3。所以這里從存儲空間來看，存放路徑最占優勢。
那麼怎麼把圖片取出來呢？
tt_image3 肯定是最容易的
tt_image1 直接導出來二進制文件即可，下面我寫了個存儲過程，導出所有圖片。
tt_image2 類似，把 select 語句里 image_file 變為 unhex(image_file) 即可。
總結
這里我舉了個用 MySQL 來存放圖片的例子，總的來說有以下三點：
Ⅳ 「mysql」的存儲類型「bit」是什麼
Bit稱為位數據類型，其數據有兩種取值：0和1，長度為1位。在輸入0以外的其他值時，系統均把它們當1看待。這種數據類型常作為邏輯變數使用，用來表示真、假或是、否等二值選擇。
Ⅳ MYSQL資料庫中，常見的數據類型有哪些
MySQL 數據類型細分下來，大概有以下幾類：
- 數值，典型代表為 tinyint,int,bigint
- 浮點/定點，典型代表為 float,double,decimal 以及相關的同義詞
- 字元串，典型代表為 char,varchar
- 時間日期，典型代表為 date,datetime,time,timestamp
- 二進制，典型代表為 binary,varbinary
- 位類型
- 枚舉類型
集合類型
Ⅵ mySQL是什麼類型的資料庫
mysql（發音為"my
ess
cue
el"，不是"my
sequel"）是一種開放源代碼的關系型資料庫管理系統（rdbms），mysql資料庫系統使用最常用的資料庫管理語言--結構化查詢語言（sql）進行資料庫管理。
由於mysql是開放源代碼的，因此任何人都可以在general
public
license的許可下下載並根據個性化的需要對其進行修改。mysql因為其速度、可靠性和適應性而備受關注。大多數人都認為在不需要事務化處理的情況下，mysql是管理內容最好的選擇。
mysql關系型資料庫於1998年1月發行第一個版本。它使用系統核心提供的多線程機制提供完全的多線程運行模式，提供了面向c、c++、eiffel、java、perl、php、python以及tcl等編程語言的編程介面（apis），支持多種欄位類型並且提供了完整的操作符支持查詢中的select和where操作。
mysql開發組計劃於2001年中期公布mysql4.0版本。在這個版本中將有以下新的特性被提供：新的表定義文件格式、高性能的數據復制功能、更加強大的全文搜索功能。在此之後，mysql開發著希望提供安全的數據復制機制、在beos操作系統上的mysql實現以及對延時關鍵字的定期刷新選項。隨著時間的推進，mysql將對ansi
92/ansi
99標准完全兼容。
時至今日
mysql
和
php
的結合絕對是完美.很多大型的網站也用到mysql資料庫.mysql的發展前景是非常光明的!
Ⅶ mysql的 存儲類型 bit 是
Bit稱為位數據類型，其數據有兩種取值：0和1，長度為1位。在輸入0以外的其他值時，系統均把它們當1看待。這種數據類型常作為邏輯變數使用，用來表示真、假或是、否等二值選擇。
Ⅷ mysql 存儲金額類型，用什麼數據類型比較可靠，一般企業數據用什麼數據類型
「數字類」，就是指 DECIMAL 和 NUMERIC，它們是同一種類型。它嚴格的說不是一種數字類型，因為他們實際上是將數字以字元串形式保存的;他的值的每一位 (包括小數點) 佔一個位元組的存儲空間，因此這種類型耗費空間比較大。但是它的一個突出的優點是小數的位數固定，在運算中不會「失真」，所以比較適合用於「價格」、「金額」這樣對精度要求不高但准確度要求非常高的欄位。
Ⅸ 關於mysql資料庫裡面數據類型number的問題
MySQL 數據類型細分下來，大概有以下幾類：
數值，典型代表為 tinyint,int,bigint
浮點/定點，典型代表為 float,double,decimal 以及相關的同義詞
字元串，典型代表為 char,varchar
時間日期，典型代表為 date,datetime,time,timestamp
二進制，典型代表為 binary,varbinary
位類型
枚舉類型
集合類型
大對象，比如 text,blob
json 文檔類型
一、數值類型（不是數據類型，別看錯了）如果用來存放整數，根據范圍的不同，選擇不同的類型。
注意：timestamp 代表的時間戳是一個 int32 存儲的整數，取值范圍為 '1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'；datetime 取值范圍為 '1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。
1. 如果時間有可能超過時間戳范圍，優先選擇 datetime。2. 如果需要單獨獲取年份值，比如按照年來分區，按照年來檢索等，最好在表中添加一個 year 類型來參與。3. 如果需要單獨獲取日期或者時間，最好是單獨存放，而不是簡單的用 datetime 或者 timestamp。後面檢索時，再加函數過濾，以免後期增加 SQL 編寫帶來額外消耗。
建立表 t5，對這些可能需要的欄位全部分離開，這樣以後寫 SQL 語句的時候就很容易了。
當然了，這種情形佔用額外的磁碟空間。如果想在易用性與空間佔用量大這兩點來折中，可以用 MySQL 的虛擬列來實時計算。比如假設 c5 欄位不存在，想要得到 c5 的結果。mysql-(ytt/3305)->alter table t5 drop c5, add c5 year generated always as (year(c1)) virtual;Query OK, 1 row affected (2.46 sec)Records: 1 Duplicates: 0 Warnings: 0
五、二進制類型
binary(10)/varbinary(10) 代表的不是字元個數，而是位元組數。
行結束符不一樣。char 的行結束符是 ，binary 的行結束符是 0x00。
由於是二進制存儲，所以字元編碼以及排序規則這類就直接無效了。
六、位類型
1. 對於 bit(8) 如果單純存放 1 位，左邊以 0 填充 00000001。2. 查詢時可以直接十進制來過濾數據。3. 如果此欄位加上索引，MySQL 不會自己做類型轉換，只能用二進制來過濾。
創建表 c1, 欄位性別定義一個比特位。mysql-(ytt/3305)->create table c1(gender bit(1));Query OK, 0 rows affected (0.02 sec)
mysql-(ytt/3305)->select cast(gender as unsigned) 'f1' from c1;+------+| f1 |+------+| 0 || 1 |+------+2 rows in set (0.00 sec)
過濾數據也一樣，二進制或者直接十進制都行。mysql-(ytt/3305)->select conv(gender,16,10) as gender -> from c1 where gender = b'1';+--------+| gender |+--------+| 1|+--------+1 row in set (0.00 sec)mysql-(ytt/3305)->select conv(gender,16,10) as gender -> from c1 where gender = '1';+--------+| gender |+--------+| 1|+--------+1 row in set (0.00 sec)
mysql-(ytt/3305)->create table c2(gender char(0));Query OK, 0 rows affected (0.03 sec)
mysql-(ytt/3305)->select count(*) from c1;+----------+| count(*) |+----------+| 33554432 |+----------+1 row in set (1.37 sec)
mysql-(ytt/3305)->insert into c2 select if(gender = 0,'',null) from c1;Query OK, 33554432 rows affected (2 min 18.80 sec)Records: 33554432 Duplicates: 0 Warnings: 0
兩張表的磁碟佔用差不多。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl總用量 1.9G4085684 933M -rw-r----- 1 mysql mysql 932M 12月 11 10:16 c1.ibd4082686 917M -rw-r----- 1 mysql mysql 916M 12月 11 10:22 c2.ibd
檢索方式稍微有些不同，不過效率也差不多。所以說，字元類型不愧為萬能類型。
七、枚舉類型
1. 最大佔用 2 Byte。2. 最大支持 65535 個不同元素。3. MySQL 後台存儲以下標的方式，也就是 tinyint 或者 smallint 的方式，下標從 1 開始。4. 排序時按照下標排序，而不是按照裡面元素的數據類型。所以這點要格外注意。
創建表 t7。mysql-(ytt/3305)->create table t7(c1 enum('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (0.03 sec)
1. 最大佔用 8 Byte，int64。2. 內部以二進制位的方式存儲，對應的下標如果以十進制來看，就分別為 1,2,4,8，...，pow(2,63)。3. 最大支持 64 個不同的元素，重復元素的插入，取出來直接去重。4. 元素之間可以組合插入，比如下標為 1 和 2 的可以一起插入，直接插入 3 即可。
mysql-(ytt/3305)->create table c7(c1 set('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (0.02 sec)
mysql-(ytt/3305)->INSERT INTO c7WITH RECURSIVE ytt_number (cnt) AS ( SELECT 1 AS cnt UNION ALL SELECT cnt + 1 FROM ytt_number WHERE cnt < pow(2, 7) )SELECT *FROM ytt_number;Query OK, 128 rows affected (0.01 sec)Records: 128 Duplicates: 0 Warnings: 0
示例 10
mysql-(ytt/3305)->select ytt_sample_data_type(1111,222) 'result';+--------------------------+| result |+--------------------------+| The result is: '246642'. |+--------------------------+1 row in set (0.00 sec)
綜上所述，日期這塊類型的選擇遵循以下原則：
4. 如果有保存毫秒類似的需求，最好是用時間類型自己的特性，不要直接用字元類型來代替。MySQL 內部的類型轉換對資源額外的消耗也是需要考慮的。
示例 5
binary 和 varbinary 對應了 char 和 varchar 的二進制存儲，相關的特性都一樣。不同的有以下幾點：
示例 6
來看這個 binary 存取的簡單示例，還是之前的變數 @a。
切記！這里要提前計算好 @a 佔用的位元組數，以防存儲溢出。
bit 為 MySQL 里存儲比特位的類型，最大支持 64 比特位， 直接以二進制方式存儲，一般用來存儲狀態類的信息。比如，性別，真假等。具有以下特性：
示例 7
其實這樣的場景，也可以定義為 char(0)，這也是類似於 bit 非常優化的一種用法。
那現在我給表 c1 簡單的造點測試數據。
把 c1 的數據全部插入 c2。
枚舉類型，也即 enum。適合提前規劃好了所有已經知道的值，且未來最好不要加新值的情形。枚舉類型有以下特性：
示例 8
八、集合類型
集合類型 SET 和枚舉類似，也是得提前知道有多少個元素。SET 有以下特點：
示例 9
定義表 c7 欄位 c1 為 set 類型，包含了 8 個值，也就是下表最大為 pow(2,7)。
插入 1 到 128 的所有組合。
九、數據類型在存儲函數中的用法
函數里除了顯式聲明的變數外，默認 session 變數的數據類型很弱，隨著給定值的不同隨意轉換。
定義一個函數，返回兩個給定參數的乘積。定義里有兩個變數，一個是 v_tmp 顯式定義為 int64，另外一個 @vresult 隨著給定值的類型隨意變換類型。
簡單調用下。
總結
本篇把 MySQL 基本的數據類型做了簡單的介紹，並且用了一些容易理解的示例來梳理這些類型。我們在實際場景中，建議選擇適合最合適的類型，不建議所有數據類型簡單的最大化原則。比如能用 varchar(100)，不用 varchar(1000)。
Ⅹ mysql資料庫中有幾種數據類型
MySQL數據類型之一字元型
VARCHAR VS CHAR
VARCHAR型和CHAR型數據的這個差別是細微的，但是非常重要。他們都是用來儲存字元串長度小於255的字元。
假如你向一個長度為四十個字元的VARCHAR型欄位中輸入數據Bill Gates。當你以後從這個欄位中取出此數據時，你取出的數據其長度為十個字元——字元串Bill Gates的長度。 現在假如你把字元串輸入一個長度為四十個字元的CHAR型欄位中，那麼當你取出數據時，所取出的數據長度將是四十個字元。字元串的後面會被附加多餘的空格。
當你建立自己的站點時，你會發現使用VARCHAR型欄位要比CHAR型欄位方便的多。使用VARCHAR型欄位時，你不需要為剪掉你數據中多餘的空格而操心。
VARCHAR型欄位的另一個突出的好處是它可以比CHAR型欄位佔用更少的內存和硬碟空間。當你的資料庫很大時，這種內存和磁碟空間的節省會變得非常重要
MySQL數據類型之二文本型
TEXT
使用文本型數據，你可以存放超過二十億個字元的字元串。當你需要存儲大串的字元時，應該使用文本型數據。
注意文本型數據沒有長度，而上一節中所講的字元型數據是有長度的。一個文本型欄位中的數據通常要麼為空，要麼很大。
當你從HTML form的多行文本編輯框(TEXTAREA)中收集數據時，你應該把收集的信息存儲於文本型欄位中。但是，無論何時，只要你能避免使用文本型欄位，你就應該不適用它。文本型欄位既大且慢，濫用文本型欄位會使伺服器速度變慢。文本型欄位還會吃掉大量的磁碟空間。
一旦你向文本型欄位中輸入了任何數據(甚至是空值)，就會有2K的空間被自動分配給該數據。除非刪除該記錄，否則你無法收回這部分存儲空間。
MySQL數據類型之三數值型
SQL支持許多種不同的數值型數據。你可以存儲整數 INT 、小數 NUMERIC、和錢數 MONEY。
INT VS SMALLINT VS TINYINT
他們的區別只是字元長度：
INT型數據的表數范圍是從-2，147，483，647到2，147，483，647的整數
SMALLINT 型數據可以存儲從-32768到32768的整數
TINYINT 型的欄位只能存儲從0到255的整數,不能用來儲存負數
通常，為了節省空間，應該盡可能的使用最小的整型數據。一個TINYINT型數據只佔用一個位元組；一個INT型數據佔用四個位元組。這看起來似乎差別不大，但是在比較大的表中，位元組數的增長是很快的。另一方面，一旦你已經創建了一個欄位，要修改它是很困難的。因此，為安全起見，你應該預測以下，一個欄位所需要存儲的數值最大有可能是多大，然後選擇適當的數據類型。
MUNERIC
為了能對欄位所存放的數據有更多的控制，你可以使用NUMERIC型數據來同時表示一個數的整數部分和小數部分。NUMERIC型數據使你能表示非常大的數——比INT型數據要大得多。一個NUMERIC型欄位可以存儲從-1038到1038范圍內的數。NUMERIC型數據還使你能表示有小數部分的數。例如，你可以在NUMERIC型欄位中存儲小數3.14。
當定義一個NUMERIC型欄位時，你需要同時指定整數部分的大小和小數部分的大小。如：MUNERIC(23,0)
一個 NUMERIC型數據的整數部分最大隻能有28位，小數部分的位數必須小於或等於整數部分的位數，小數部分可以是零。
MONEY VS SMALLMONEY
你可以使用 INT型或NUMERIC型數據來存儲錢數。但是，專門有另外兩種數據類型用於此目的。如果你希望你的網點能掙很多錢，你可以使用MONEY型數據。如果你的野心不大，你可以使用SMALLMONEY型數據。MONEY型數據可以存儲從-922，337，203，685，477.5808到922，337，203，685，477.5807的錢數。如果你需要存儲比這還大的金額，你可以使用NUMERIC型數據。
SMALLMONEY型數據只能存儲從-214，748.3648到214，748.3647 的錢數。同樣，如果可以的話，你應該用SMALLMONEY型來代替MONEY型數據，以節省空間。
MySQL數據類型之四邏輯型
BIT
如果你使用復選框( CHECKBOX)從網頁中搜集信息，你可以把此信息存儲在BIT型欄位中。BIT型欄位只能取兩個值：0或1。
當心，在你創建好一個表之後，你不能向表中添加 BIT型欄位。如果你打算在一個表中包含BIT型欄位，你必須在創建表時完成。
MySQL數據類型之五日期型
DATETIME VS SMALLDATETIME
一個 DATETIME型的欄位可以存儲的日期范圍是從1753年1月1日第一毫秒到9999年12月31日最後一毫秒。
如果你不需要覆蓋這么大范圍的日期和時間，你可以使用SMALLDATETIME型數據。它與DATETIME型數據同樣使用，只不過它能表示的日期和時間范圍比DATETIME型數據小，而且不如DATETIME型數據精確。一個SMALLDATETIME型的欄位能夠存儲從1900年1月1日到2079年6月6日的日期，它只能精確到秒。
DATETIME型欄位在你輸入日期和時間之前並不包含實際的數據，認識這一點是重要的。