摘要：主要以的或?yàn)槔渌麛?shù)據(jù)庫(kù)中基本也有類(lèi)型并需要提供長(zhǎng)度的參數(shù)。以前的版本的最大長(zhǎng)度就是，之后是。而之后表示長(zhǎng)度的字節(jié)數(shù)會(huì)變成個(gè)。盡管是動(dòng)態(tài)存儲(chǔ)的，但別的數(shù)據(jù)庫(kù)引擎不一定是如此。不管其中每一行存儲(chǔ)的數(shù)據(jù)是長(zhǎng)還是短。

  
http://dba.stackexchange.com/questions/76469/mysql-varchar-length-and-...

主要以mysql的InnoDB或MyISAM為例，其他數(shù)據(jù)庫(kù)中基本也有varchar類(lèi)型并需要提供長(zhǎng)度的參數(shù)。
需要說(shuō)明的是，例如VARCHAR(3)表示的是這一列最多存3個(gè)字符而不是3個(gè)字節(jié)，比如可以存“一二三”，實(shí)際存儲(chǔ)時(shí)是編碼為utf-8的。

在mysql中，VARCHAR(3)和VARCHAR(255)在存儲(chǔ)方式上是沒(méi)有區(qū)別的，都是1個(gè)字節(jié)表示字符串長(zhǎng)度和字符串經(jīng)utf-8編碼后的字節(jié)。mysql5.0.3以前的版本varchar的最大長(zhǎng)度就是255，之后是65535。而VARCHAR(256)之后表示長(zhǎng)度的字節(jié)數(shù)會(huì)變成2個(gè)。其實(shí)在今天來(lái)說(shuō)多一個(gè)字節(jié)也沒(méi)什么區(qū)別，但為了兼容性，通常的數(shù)據(jù)庫(kù)設(shè)計(jì)中還是會(huì)出現(xiàn)很多VARCHAR(255)。

但事實(shí)上，把所有較短的字符串列都設(shè)為VARCHAR(255)并不是最好的做法。盡管InnoDB是動(dòng)態(tài)存儲(chǔ)的，但別的數(shù)據(jù)庫(kù)引擎不一定是如此。有的可能會(huì)使用固定長(zhǎng)度的行，或者固定大小的內(nèi)存表。內(nèi)存表即為sql查詢(xún)中產(chǎn)生的臨時(shí)表。它通常會(huì)為varchar類(lèi)型分配最大的空間，比如utf-8編碼下，內(nèi)存表可能要為VARCHAR(255)分配2+3×255字節(jié)（2是因?yàn)榇娴氖亲止?jié)長(zhǎng)度而不是字符長(zhǎng)度），如果行數(shù)非常多，這也會(huì)帶來(lái)性能問(wèn)題。不管其中每一行存儲(chǔ)的數(shù)據(jù)是長(zhǎng)還是短。另外也注意到InnoDB的單列索引每個(gè)結(jié)點(diǎn)的最大是767字節(jié)（即2+3×255）。

InnoDB最大的行的大小是半個(gè)database page（大約8000字節(jié)），如果可變長(zhǎng)的列（如varbinary、varchar、text、blob）超過(guò)了這個(gè)大小會(huì)被存到外面去，行里面只是存一個(gè)指針。這會(huì)比存inline慢很多。提到這個(gè)不得不說(shuō)一下text類(lèi)型，text的存儲(chǔ)方法應(yīng)該和varchar也沒(méi)什么區(qū)別，就是沒(méi)有長(zhǎng)度的限制，因此它在有join等產(chǎn)生中間結(jié)果的查詢(xún)中會(huì)非常慢。

所以結(jié)論是，我們應(yīng)該用盡可能小的類(lèi)型而不是統(tǒng)一用VARCHAR(255)。