根据自己多年的工作经验，特别是在接收旧的项目时，varcahr的长度设置有不同的风格，针对varchar长度的设置问题，自己划分了不同的门派。

1.强迫症派：长度设置为4或者8的倍数，达到内存对齐的目的;

2.贴心派：长度设置成(2^n)-1；

3.务实派：需要多长就设置多长，不关心2的几次幂；

4.逍遥派：varchar是存储可变长字符串的，n值尽可能设置的大，比如varchar(1000)。

下面分析那种方案更合理：

1.varchar(n)的最大值字符数是多少

varchar的最大可以保存65535字节，但是具体保存多少个字符，不同的编码不一样。

MySql 5.0 之前的版本: n指的是n个字节

n的最大值是65535，如果存放utf-8格式只能保存 (n / 3)个汉字，即如果varchar(20) 那么只能保存6个汉字；

MySql 5.0 之后的版本: n指的是n个字符

如果存放utf-8格式，那么无论是数字，字母还是汉字，都可存放n个，即如果varchar(20) 那么可以保存20个汉字(自己亲测可以);

gbk类型：varchar(n)中每个字符最多占2个字节，最大长度不能超过(65535 / 2);

utf-8类型：varchar(n)中每个字符最多占3个字节，最大长度不能超过(65535 / 3)。

2.varchar(n)需要1到2个额外字节记录长度n的值

当n<=255的时候，只需要1个字节记录即可(数据表示范围：0 ~ (2^8-1)，即0~255)；当n>255的时候，则需要2个字节存储n的值((2^8)~ (2^16)-1，即256~65535)。

varchar字段报错的实际值得长度保存在第一个或者前两个字节中。

所以：

a.如果varchar(20)，实际是需要1+20个字节的存储空间;

b.如果varchar(255)，实际是需要1+255个字节的存储空间;

c.如果varchar(256)，实际是需要2+256个字节的存储空间;

d.如果varchar(500)，实际是需要2+500个字节的存储空间.

因此1.强迫症派的n=4或者8的倍数达到内存对齐的目的是不成立的，如果要达到内存对齐，varchar长度应该为(2^n)-1才能够达到，所以强迫症派的方法不可取。

3.varchar的内存对齐的问题

因为varchar是存储可变长字符串，

因此：

a.如果name varchar(8)，那么name='12345678'，实际长度为1+8；

b.如果name varchar(32)，那么name='12345678'，实际长度为1+8；

c.如果name varchar(16)，那么name='1234'，实际长度为1+4；

估：

贴心派的varchar长度应该为(2^n)-1是不能够达到内存对齐的目的的，长度是以实际保存的字符串长度为准的，因此贴心派也是不准确的。

另外，InnoDB是以页(page)为基本的存储单位，一个页会有一行或者多行(row)数据，数据的读取是基于page的，不是按照row读取的，因此也就没有内存对齐的问题了。

4.n值尽可能设置的大的问题

逍遥派的结论一看就不靠谱，但是还是需要理论进行驳斥的。

在MySql在查询是需要创建临时表的时候(union，order by、group by，子查询)，在MySql读取数据之前，是只知道varchar的长度n，不知道实际数据的长度的，但是读取数据之前需要预分配内存空间，MySql是根据varchar(n)中的n来进行分配内存的，这样也是最合理的方式，不可能分配小于n个字符的空间，因此针对逍遥派的varchar(1000)设置就会预先分配1000个字符空间，很显然这个是十分不靠谱的设计。

结论：

varchar需要多长就设置多长，不必考虑2的多少次幂的问题。但是如果遇到了varchar(256)这种情况，你为啥不将他设置为varchar(255)呢，明显节省了一个存储长度的字节呀。因此务实派方案虽然最靠谱，但是也是要考虑255这个界限的。