- 测试环境
- 表信息
表数据量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。