根据自己多年的工作经验，特别是在接收旧的项目时，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个字符空间，很显然这个是十分不靠谱的设计。
