欢迎指正，转载注明出处。大胡子_biu
测试0 批量插入和逐条插入
批量插入10万条数据大约是1.162秒，逐条插入大约是86秒
测试1 自增id和uuid
表A结构如下
表B结构如下
表A主键为自增长整数，parentid为十位重复数字。
表B的uuid和parentid由mysqluuid()函数获得。
两个表的name字段值相同，nowtime值相同。
累计插入数据150W条。
以下为两个表count(*)
查询5次
表b查询时间为0.829s 0.863s 0.868s 0.835s 0.821s
表a查询时间为0.384s 0.383s 0.372s 0.368s 0.366s
表b的平均查询时间约为表a的两倍
猜测1
数据库的数据以聚合的形式存储在磁盘块中，内存读取数据后在内存中的操作占整体时间的比例微乎其微，因此主要时间为读取磁盘数据的时间。磁盘块是IO的最小单位，由于表b的单条数据量大于表a，所以整体时间大于表a。
测试2 留空余空间和刚好占满
uuid的实际长度是32+4个分隔符=36，所以实际varchar(36)也足以存放数据，这里将uuid表的字段长度修改为36，别名为c
查询五次
分别时间为 0.469s 0.472s 0.464s 0.466s
猜测2
理论上来讲，varchar36和varchar40占据的空间应该是一样的，字符长度标志+实际字符串长度。
但是这里有较大出入，我尝试将varchar改为37，查询时间和36没有太大差距。
将varchar改为50，和varchar40没有太大差别，甚至会快0.01-0.03秒。
暂时没有理论依据支持。
测试3 varchar改为char
将表c的varcha改为char，插入一百五十万条数据，表结构如下，设为表d
查询5次
结果分别为
0.464s 0.460s 0.459s 0.464s 0.459s
猜测3
字符长度位对整体影响并不大。
测试4 int设置长度
由于id表数字最大长度是7位，设置int长度8位，查询五次，结果如下。
0.348s 0.345s 0.349s 0.345s 0.343s
相比测试1而言确实有约10%的提升。
猜测4
缩减int长度确实可以优化查询
总结
1、数据查询主要取决于磁盘块IO的次数，浪费空间造成磁盘块占据多IO次数多，查询速度慢，设计表时最好不要浪费空间。
2、由于数据库的优化，在数据长度普遍相同的情况下（都是30的长度，而不是大多数只有5，少部分30这种情况）varchar和char并没有太大区别