MySQL零散筆記– 資料類型

來源:互聯網
上載者:User

今天準備進行畢設的資料庫設計,所以google了一下MySQL的資料庫設計原則,主要是資料類型和表設計,為了怕自己忘記整理出來。

Reference 文章:MySQL 欄位類型 作者:simaopig

類型 描述
INT 一種數實值型別,值的範圍如下 帶符號的-2147483648~2147483647 不帶符號的0~4294967295 最多十位,所以存手機號是不行的
DECIMAL 一種數實值型別,支援浮點數或者小數
DOUBLE 一種數實值型別,支援雙精確度浮點數
DATE YYYYMMDD格式的日期欄位
TIME HH:MM:SS格式的時間欄位
DATETIME YYMMDD HH:MM:SS格式的日期/時間類型.注意“年月日”與“時分秒”之間的空格
YEAR 以YYYY或YY格式,範圍在1901~2155之間指定的年欄位 別問我2155年後咋辦,我估計我活不到那年
TIMESTAMP 以YYYYMMDDHHMMSS格式的時間戳記
CHAR 最大長度為255個字元且有固定長度的字串類型
VARCHAR 最大長度為255個字元但是變長的字串類型
TEXT 最大長度為65535個字元的字串的類型
BLOB 可變資料的二進位類型
ENUM 可以從定義數值的列表上接受值的資料類型
SET 可以從定義數值的集合上接受0個或者多個值的資料類型
 一些例子代碼:
CREATE TABLE data (id TINYINT );
INSERT INTO data VALUES (123456789);
SELECT id FROM data;

因為TINYINT的儲存範圍是(-128,127),所以查詢結果為127。

CREATE TABLE data (speed FLOAT(3,1));
INSERT INTO data VALUES(123.765);
SELECT speed FROM data

其查詢結果為123.8這就是四捨五入的結果

預設情況下,MySQL是大小寫不敏感的,例如:

CREATE TABLE data (name CHAR(5));
INSERT INTO data VALUES ('HUGO');
SELECT * FROM data WHERE name = 'hugo'

hugo會被搜出來。

BINARY關鍵字,它告訴MySQL, 之後的字串應該以二進位方式被處理。這時,當在字串上執行比較子時,MySQL將牢牢記住字串的大小寫。CHAR和VARCHAR都適用此修飾符。

ALTER TABLE data CHANGE CHAR(5) BINARY;
SELECT * FROM data WHERE name = 'hugo'

這樣就好啦!就找不到hugo了

“CHAR類型和VACHAR之間的差別在於MySQL處理這個指標(長度指標)的方式不同:CHAR把這個大小視為值的準確大小(用空格填補比較短的值,所以達到了這個大小),而VARCHAR類型把它視為最大值並且只使用了在儲存字串實際上需要的位元組數(增加一個額外的位元組記錄長度)”

“TEXT和BLOB類型在分類和比較的方式上不同,BLOB類型區分大小寫,TEXT類型不區分大小寫。MySQL手冊用“TEXT類型是不區分大小寫BLOB類型”最準確地說明了這一點。”

CREATE TABLE data (birthday DATE);
INSERT INTO data VALUES ('2009-04-07'),(20090407);
SELECT birthday FROM data;

結果都是”2009-04-07″, MySQL預設使用'-'分隔日期,用':'分隔時間

DROP TABLE data;
CREATE TABLE data (showtime TIME);
INSERT INTO data VALUES('12:30:56'),('12:30'),(123056);
SELECT showtime FROM data;

查詢結果為“12:30:56″,”12:30:00″,”12:30:56″.

MySQL還對日期的年份中的兩個數位值,或是語句為YEAR類型的輸入欄位中的兩個數字輸入執行這種類型的最大限度的通譯。因為所有的YEAR類型的值必須用4個數字來儲存,所有MySQL試圖根據值的數字範圍把兩個數位年份值轉換為4個數位值:把在00~69範圍內的值轉換到2000~2069範圍內,而把70~99範圍內的值轉換到1970~1979之內。

問題:

資料類型如何設計?使用者ID使用數值型還是字元型為好?

一些搜來的建議:

ID類型的文字欄位,比如客戶 ID或定單號等等都應該設定得比一般想象更大,因為時間不長你多半就會因為要添加額外的字元而難堪不已。比方說,假設你的客戶ID為 10位元長。那你應該把資料庫表欄位的長度設為12或者 13個字元長。這算浪費空間嗎?是有一點,但也沒你想象的那麼多:一個欄位加長 3個字元在有1百萬條記錄,再加上一點索引的情況下才不過讓整個資料庫多佔據3MB的空間。但這額外佔據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.