数据库类型空间效率探索（三）-char

• 测试环境

• 表信息

表数据量22.23万，占用空间44.494M

• 用到的sql语句

增加列：alter table t_type add column new_column char(1) default null;

修改列：alter table t_type modify new_column char(200) default null;

删除列：alter table t_tpye drop column new_column;

表占用空间：

select concat(round(sum(data_length/1024/1024),3),'MB') as data_size,
concat(round(sum(max_data_length/1024/1024),3),'MB') as max_data_length,
concat(round(sum(data_free/1024/1024),3),'MB') as data_free,
concat(round(sum(index_length/1024/1024),3),'MB') as index_length
from information_schema.tables where table_name='t_type'

• 测试结果

见如下表格：

占用空间	char(1) default null	char(50) default null	char(100) default null	char(200) default null
data_size(MB)	45.123	44.922	44.922	44.922
index_length(MB)	2.256	2.256	2.256	2.256
data_free(MB)	0	0	0	0
占用空间	char(1) not null default ''	char(50) not null default ''	char(100) not null default ''	char(200) not null default ''
data_size(MB)	44.922	44.721	44.721	44.721
index_length(MB)	2.256	2.256	2.256	2.256
data_free(MB)	0	0	0	0

向new_column char(200) not null default ''插入字符N个a啊
占用空间插入字符	1（a啊）	2（aa啊啊）	2(a啊/啊a)	3(aaa/啊哈呵)	35(a…a/啊…的/全半角混合)
data_size(MB)	45.72946.733	46.73348.961	48.961/48.961	48.961/48.961	63.377/66.617/67.617
index_length(MB)	2.256	2.256	2.256	2.256	2.256
data_free(MB)	0	0	0	0	4.24

这个时候，当插入35个字符时，产生了奇怪的现象，看下面截图

• 重要步骤

可以看到，随着不断的更新字段中的数据，更新所耗费的时间逐渐增加（4.75->5.77->6.89->8.30），插入的最后一条数据（8.30sec），产生了4.240M的内存碎片。

优化表

优化后，表的大小明显减小，index_length也相应减小。

之前以为优化后的data_size为优化前的data_size减去data_free，看来不是这个样子。

通过上面的测试，对于char类型的字段，我得出了如下结论：

• 结论：

1、对于char类型，char(1)占用的空间反而比char(50)占用的多。

2、char(N)随着N的增多，表占用的空间并没有增大，这样就和N多大就分配多大的说法相矛盾。所以下面斜体字说法是错误的：

char类型时定长的类型，即当定义的是char(10)，输入的是"abc"这三个字符时，它们占的空间一样是10个字节，包括7个空字节。

3、在更新大量数据的时候，如果插入次数过多（我测试的也不多，也就比上面摆出的多了三次），会严重影响mysql的插入速度与性能。

4、随着字段中数据量的增多，表占用的空间并不是一成不变的。而且也并没有根据插入字符所占字节的多少呈现符合常理的变化。

注：怪不得别人都说mysql是个坑，如果这样的话，这样就应该解决了前几天的那个疑问，也解决了我之前一直想不清楚的疑问。如何解决这个问题，还需要更深一步的研究一下mysql。