摘要:和數據類型的用法在存儲字符串時,可以使用或者類型相同點和都可以存儲變長字符串且字符串長度上限為字節不同點速度快,不存在空間浪費,不處理尾部空格,上限為字節,但是有存儲長度實際字節最大可用。
點贊再看,養成贊美的習慣,微信搜一搜【香菜聊游戲】關注我。
目錄
MySQL中有多種表示時間日期的數據類型,主要有YEAR、TIME、DATE、DATETIME、TIMESTAMP等
datetime和timestamp都可以表示 YYYY-MM-DD HH:MM:SS 這種年月日時分秒格式的數據。
datetime存儲與時區無關(準備來說是datetime只支持一個時區,就是存儲時當前服務器的時區),而timestamp存儲的是與時區有關。
datetime、timestamp精確度都是秒,datetime與時區無關,存儲的范圍廣(1001-9999),timestamp與時區有關,存儲的范圍小(1970-2038)。
TIMESTAMP和DATETIME除了存儲范圍和存儲方式不一樣,沒有太大區別。當然,對于跨時區的業務,TIMESTAMP更為合適。
mysql在存儲字符串時, 可以使用char、varchar或者text類型
varchar 和 text 都可以存儲變長字符串且 字符串長度上限為65535字節
varchar 速度快,不存在空間浪費,不處理尾部空格,上限為65535字節,但是有存儲長度實際65532字節最大可用。255字節以下用1字節存儲長度,255字節以上用2字節存儲長度。 text,存變長大數據,速度慢,不存在空間浪費,不處理尾部空格,上限65535字節,會用額外空間存放數據長度,顧可以全部使用65535字節。
不能在TEXT列上放置索引(全文索引除外),對于text來說,只能添加前綴索引,并且前綴索引最大只能達到1000字節
text沒有默認值
當varchar大于某些數值的時候,其會自動轉換為text,大概規則如下:
大于varchar(255)變為 tinytext
大于varchar(500)變為 text
大于varchar(20000)變為 mediumtext
1、經常變化的字段用varchar;
2、知道固定長度的用char;
3、超過255字節的只能用varchar或者text;
4、能用varchar的地方不用text;
5、能夠用數字類型的字段盡量選擇數字類型而不用字符串類型,這會降低查詢和連接的性能,并會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字符串中每一個字符,而對于數字型而言只需要比較一次就夠了;
6、存儲引擎對于選擇 CHAR 和 VARCHAR 的影響:
對于 MyISAM 存儲引擎,最好使用固定長度的數據列代替可變長度的數據列。這樣可以使整個表靜態化,從而使數據檢索更快,用空間換時間。
對于InnoDB存儲引擎,最好使用可變長度的數據列,因為 InnoDB 數據表的存儲格式不分固定長度和可變長度,因此使用 CHAR 不一定比使用 VARCHAR 更好,但由于 VARCHAR 是按照實際的長度存儲,比較節省空間,所以對磁盤 I/O 和數據存儲總量比較好。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/125342.html
摘要:微信公眾號后端進階,專注后端技術分享框架分布式中間件服務治理等等。 微信公眾號「后端進階」,專注后端技術分享:Java、Golang、WEB框架、分布式中間件、服務治理等等。 老司機傾囊相授,帶你一路進階,來不及解釋了快上車! 我發現數據庫有些日期居然用字符串保存?于是跟幾個小伙伴討論了關于數據庫的日期應該要怎么保存的問題,其實我一直都建議直接用數值保存時間戳,為什么我要這么建議呢?...
摘要:示例指定了也就是零時區,顯示的時間會加上本地時區的偏移小時。其實就是上面顯示時間時使用的形式除了能表示基本信息,還可以表示星期,但是一點也不容易讀,不建議使用。 原文對 ISO 8601 時間格式中 T 和 Z 的表述有一些錯誤,我已經對原文進行了一些修訂,抱歉給大家造成誤解。 最近使用 sequelize 過程中發現一個奇怪的問題,將某個時間插入到表中后,通過 sequelize 查...
閱讀 3801·2023-01-11 11:02
閱讀 4307·2023-01-11 11:02
閱讀 3130·2023-01-11 11:02
閱讀 5238·2023-01-11 11:02
閱讀 4802·2023-01-11 11:02
閱讀 5575·2023-01-11 11:02
閱讀 5379·2023-01-11 11:02
閱讀 4080·2023-01-11 11:02