快捷導(dǎo)航

深入研究mysql中的varchar和limit(容易被忽略的知識(shí))

更新時(shí)間：2015年03月10日 08:58:35 投稿：junjie

這篇文章主要介紹了深入研究mysql中的varchar和limit(容易被忽略的知識(shí)),本文探究了varchar(5)可以存儲(chǔ)多少個(gè)漢字、多少個(gè)字母數(shù)字和mysql中的limit你真的會(huì)用嗎兩個(gè)知識(shí)點(diǎn),需要的朋友可以參考下

為什么標(biāo)題要起這個(gè)名字呢？commen sence指的是那些大家都應(yīng)該知道的事情，但往往大家又會(huì)會(huì)略這些東西，或者對(duì)這些東西一知半解，今天我總結(jié)下自己在mysql中遇到的一些commen sense類型的問題。

　　1、varchar(5)可以存儲(chǔ)多少個(gè)漢字，多少個(gè)字母數(shù)字？

　　相信有好多人應(yīng)該跟我一樣，對(duì)這個(gè)已經(jīng)很熟悉了，根據(jù)經(jīng)驗(yàn)我們能很快的做出決定，比如說用varchar(200)去存儲(chǔ)url等等，但是，即使你用了很多次也很熟悉了，也有可能對(duì)上面的問題做出錯(cuò)誤的回答。

　　這個(gè)問題我查了好多資料，有的人說是可以存儲(chǔ)5個(gè)字符，2.5個(gè)漢字（每個(gè)漢字占用兩個(gè)字節(jié)的話），有的人說這個(gè)要區(qū)分版本，5.0是個(gè)分界限，5.0之前是前面說的那樣，5.0之后是可以存儲(chǔ)5個(gè)“字”，不區(qū)分是數(shù)字、英文、漢字，果真是這樣嗎，我們來做個(gè)實(shí)驗(yàn)：

復(fù)制代碼代碼如下:

CREATE TABLE `test` (

  `name` varchar(5) NOT NULL DEFAULT '',

  `info` char(5) NOT NULL DEFAULT '',

  PRIMARY KEY (`name`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

　　可以看出varchar（5）中的5代表的是5個(gè)“字”，而不是5個(gè)字節(jié)（bytes），當(dāng)我們存儲(chǔ)長度超過制定長度的時(shí)候會(huì)將超過的部分“咔嚓”掉，我的mysql版本是5.6，字符集（charset）utf8和gbk是一樣的。

其他版本我電腦上沒有，去官方文檔看看有沒有什么說明，在官方文檔中查了半天終于發(fā)現(xiàn)了點(diǎn)區(qū)別：

下面這段來自http://dev.mysql.com/doc/refman/4.1/en/char.html，是對(duì)mysq4.1的說明：

復(fù)制代碼代碼如下:

The CHAR and VARCHAR types are declared with a length that indicates the maximum number of characters you want to store. For example, CHAR(30) can hold up to 30 characters. (Before MySQL 4.1, the length is interpreted as number of bytes.)

再看看其他版本的類似的說明：

復(fù)制代碼代碼如下:

The CHAR and VARCHAR types are declared with a length that indicates the maximum number of characters you want to store. For example, CHAR(30) can hold up to 30 characters.

　顯而易見了，官方文檔說了，mysql版本小于4.1的時(shí)候存儲(chǔ)的時(shí)候符合說法：varchar(5)保存5個(gè)bytes，及5個(gè)英文數(shù)字或者2.5個(gè)漢字（假設(shè)一個(gè)漢字2個(gè)字節(jié)）；

mysql版本大于等于4.1的時(shí)候varchar(5)中的5不再是字節(jié)數(shù)了，應(yīng)該理解為“字”這里的字的意思是一個(gè)漢字和一個(gè)英文或者數(shù)字“相同對(duì)待”

　　2、mysql中的limit，你真的會(huì)用嗎？

　　你在項(xiàng)目中怎么使用limit？limit num?還是limit num1,num2？還是其他的？要知道limit使用不同的形式性能差距很大的。

　　我自己測試了下，在一張innodb表中去使用limit，表中10000條數(shù)據(jù)，四個(gè)字段，id（int）、time（int）、title（varchar）、body（mediumtext），大小大約170M左右，首先關(guān)掉查詢緩存，免得查詢緩存對(duì)查詢時(shí)間有影響，這里要注意time字段上面加了索引，

復(fù)制代碼代碼如下:

SET @@query_cache_type=ON;

SET GLOBAL query_cache_size=0;

　　打開Query profiler來查看語句執(zhí)行所花費(fèi)的時(shí)間

復(fù)制代碼代碼如下:

set profiling=1;

　　接下來對(duì)下面幾個(gè)語句進(jìn)行執(zhí)行

復(fù)制代碼代碼如下:

a、SELECT id,TIME,title FROM cnblogs WHERE TIME>=1315646940 ORDER BY TIME ASC LIMIT 2000,10

　　b、SELECT id,TIME,title FROM cnblogs WHERE TIME>=1315646940 ORDER BY TIME ASC LIMIT 10

c、 SELECT id,TIME,title FROM cnblogs ORDER BY TIME ASC LIMIT 3000,10

執(zhí)行順序a，b，c，a，b，c，c，a，a（這里需要注意下，雖然我關(guān)閉了緩存，但是上一次的查詢還是會(huì)緩存，這個(gè)可以從Query profiler中看出來，所以進(jìn)行交叉執(zhí)行），使用下面的語句查看結(jié)果

復(fù)制代碼代碼如下:

SHOW profiles;

從上面的語句執(zhí)行時(shí)間分析可以看出，不考慮緩存因素，當(dāng)使用limit的時(shí)候，"limit begin,num"這種形式比"limit num"這種形式效率低很多，因此，在使用的時(shí)候盡可能的使用第二種形式，比如說要循環(huán)獲取一個(gè)表里面的數(shù)據(jù)，一次取出來內(nèi)從放不下，這個(gè)時(shí)候就要按照id（或者其他排序字段）進(jìn)行l(wèi)imit了，我們就可以通過獲取上次的該字段臨界值作為下次取數(shù)據(jù)的最小值，使用limit num這種形式效率會(huì)高很多。

您可能感興趣的文章: