MySQL对数字和字符串型数据的读取操作比较
[
2006年12月25日 23:41 | by gs ]
2006年12月25日 23:41 | by gs ]
续上次的用十进制保存颜色代码的研究
本次研究主要测试是不是在MySQL中对整型字段的操作要比对字符串型字段的操作快
我单独建立了一个数据库，在里面单独建立了一个表，只有一个字段，就是用来测试的字段。
测试方法：
读取VARCHAR(6)类型字段和MEDIUMINT(8)字段各5000次，重复进行5便，计算耗时
写入"ABCDEF"到VARCHAR(6)字段和写入100000到MEDIUMINT(8)字段各1000次，重复进行5遍，计算耗时
以上操作均使用PHP完成
测试环境：
Windows XP Professonal with SP2
Apache 2.2.3
MySQL 5.0.25
PHP版本 5.2.0
测试开始以后，我在旁边同时聊QQ（因为每次执行都要近半分钟），同时看着任务管理器中Apache和MySQL进程对CPU的占用情况。Apache和MySQL对CPU的占用都是20%~30%，因此查询操作可以说已经是全速进行了，几乎没有受到其他正在进行的操作的影响（比如说我聊QQ……）
每次得出结果我都记录下来，最后对结果进行统计
测试结果：
测试结果主要是计算平均值，计算5次操作的平均值，然后再将5次操作中最大值和最小值去掉，再计算平均值，结果如下（单位：毫秒）
测试项目 5次平均 3次平均
插入MEDIUMINT 23308.648 22765.856
插入VARCHAR 22820.456 22825.593
查询MEDIUMINT 22298.686 22277.976
查询VARCHAR 23261.500 23253.640
可以看出，两者相差不大，可以说是一样的。由此我们可以得知，MySQL对字符型字段和整型字段的读写速度是相同的（就算有差别也可以忽略不计）
结论：
MySQL对字符型字段和整型字段在查询和写入所耗费的时间上是相同的。
===============================================
附：原始测试数据
------------------------------------------------------------------------------
*21978.138208389ms in insert 1000 record in MEDIUMINT(8)
22330.047130585ms in insert 1000 record in MEDIUMINT(8)
23317.905187607ms in insert 1000 record in MEDIUMINT(8)
*26267.531871796ms in insert 1000 record in MEDIUMINT(8)
22649.605035782ms in insert 1000 record in MEDIUMINT(8)
average in all data: 23308.648
delete biggest and smallest average: 22765.856
23122.699975967ms in insert 1000 record in VARCHAR(6)
*23809.734106064ms in insert 1000 record in VARCHAR(6)
21970.224142075ms in insert 1000 record in VARCHAR(6)
23383.861064911ms in insert 1000 record in VARCHAR(6)
*21815.769195557ms in insert 1000 record in VARCHAR(6)
average in all data: 22820.456
delete biggest and smallest average: 22825.593
22309.039115906ms in select 1000 MEDIUMINT(8) records 5000 times
22427.669048309ms in select 1000 MEDIUMINT(8) records 5000 times
22097.222089767ms in select 1000 MEDIUMINT(8) records 5000 times
*22080.224990845ms in select 1000 MEDIUMINT(8) records 5000 times
*22579.282045364ms in select 1000 MEDIUMINT(8) records 5000 times
average in all data: 22298.686
delete biggest and smallest average: 22277.976
*23562.417984009ms in select 1000 VARCHAR(6) records 5000 times
*22984.163999557ms in select 1000 VARCHAR(6) records 5000 times
23248.642206192ms in select 1000 VARCHAR(6) records 5000 times
23285.526990891ms in select 1000 VARCHAR(6) records 5000 times
23226.745128632ms in select 1000 VARCHAR(6) records 5000 times
average in all data: 23261.500
delete biggest and smallest average: 23253.640
本次研究主要测试是不是在MySQL中对整型字段的操作要比对字符串型字段的操作快
我单独建立了一个数据库，在里面单独建立了一个表，只有一个字段，就是用来测试的字段。
测试方法：
读取VARCHAR(6)类型字段和MEDIUMINT(8)字段各5000次，重复进行5便，计算耗时
写入"ABCDEF"到VARCHAR(6)字段和写入100000到MEDIUMINT(8)字段各1000次，重复进行5遍，计算耗时
以上操作均使用PHP完成
测试环境：
Windows XP Professonal with SP2
Apache 2.2.3
MySQL 5.0.25
PHP版本 5.2.0
测试开始以后，我在旁边同时聊QQ（因为每次执行都要近半分钟），同时看着任务管理器中Apache和MySQL进程对CPU的占用情况。Apache和MySQL对CPU的占用都是20%~30%，因此查询操作可以说已经是全速进行了，几乎没有受到其他正在进行的操作的影响（比如说我聊QQ……）
每次得出结果我都记录下来，最后对结果进行统计
测试结果：
测试结果主要是计算平均值，计算5次操作的平均值，然后再将5次操作中最大值和最小值去掉，再计算平均值，结果如下（单位：毫秒）
测试项目 5次平均 3次平均
插入MEDIUMINT 23308.648 22765.856
插入VARCHAR 22820.456 22825.593
查询MEDIUMINT 22298.686 22277.976
查询VARCHAR 23261.500 23253.640
可以看出，两者相差不大，可以说是一样的。由此我们可以得知，MySQL对字符型字段和整型字段的读写速度是相同的（就算有差别也可以忽略不计）
结论：
MySQL对字符型字段和整型字段在查询和写入所耗费的时间上是相同的。
===============================================
附：原始测试数据
------------------------------------------------------------------------------
*21978.138208389ms in insert 1000 record in MEDIUMINT(8)
22330.047130585ms in insert 1000 record in MEDIUMINT(8)
23317.905187607ms in insert 1000 record in MEDIUMINT(8)
*26267.531871796ms in insert 1000 record in MEDIUMINT(8)
22649.605035782ms in insert 1000 record in MEDIUMINT(8)
average in all data: 23308.648
delete biggest and smallest average: 22765.856
23122.699975967ms in insert 1000 record in VARCHAR(6)
*23809.734106064ms in insert 1000 record in VARCHAR(6)
21970.224142075ms in insert 1000 record in VARCHAR(6)
23383.861064911ms in insert 1000 record in VARCHAR(6)
*21815.769195557ms in insert 1000 record in VARCHAR(6)
average in all data: 22820.456
delete biggest and smallest average: 22825.593
22309.039115906ms in select 1000 MEDIUMINT(8) records 5000 times
22427.669048309ms in select 1000 MEDIUMINT(8) records 5000 times
22097.222089767ms in select 1000 MEDIUMINT(8) records 5000 times
*22080.224990845ms in select 1000 MEDIUMINT(8) records 5000 times
*22579.282045364ms in select 1000 MEDIUMINT(8) records 5000 times
average in all data: 22298.686
delete biggest and smallest average: 22277.976
*23562.417984009ms in select 1000 VARCHAR(6) records 5000 times
*22984.163999557ms in select 1000 VARCHAR(6) records 5000 times
23248.642206192ms in select 1000 VARCHAR(6) records 5000 times
23285.526990891ms in select 1000 VARCHAR(6) records 5000 times
23226.745128632ms in select 1000 VARCHAR(6) records 5000 times
average in all data: 23261.500
delete biggest and smallest average: 23253.640
记录一下用颜色代码和用十进制数保存颜色的数据量
[ 2006年12月24日 01:19 | by gs ]
2006年12月24日 01:19 | by gs ]
如果用颜色代码的话就是 FFFFFF 这种类型的
如果用十进制就是把颜色代码转换成十进制来保存，比如上面的FFFFFF就变成16777215
如果对于这种蓝色 0000FF，其十进制为 256，这样以文本形式传输就只要3个字节，比颜色代码的6个字节要少
对于1000多万种颜色，我算了一下平均每个颜色要多少字节来表示
使用颜色代码就是6字节
使用十进制的话约7.33字节
比直接使用颜色代码大，多出了22.17%
但是，使用十进制进行保存（不是输出为字符串）的时候，只要占用3个字节，也就是2^(3*8)种颜色
其实，如果使用有符号数的话，用十进制可以比颜色代码更短
用有符号数，3字节长的整型有符号变量，范围是-8388608~8388607
这样，如果是正数的话，输出为字符串就只用7个字节，负数才用8个字节，大约比用无符号数的时候少了一半
计算了一下，使用无符号数的话，平均每个颜色值长度是4.59个字节，比颜色代码的6字节少了23.5%
在储存的时候也占用更小的空间
所以，在某些情况下，保存颜色代码用十进制有符号数来表示是比较好的
---------------------------------
更深一步
在新的CSS标准中，对于FF00FF这种颜色，可以简写为F0F，这就减少了代码长度
我计算了一下，这样的话平均颜色代码长度约为5.99927，缩减的量可以忽略……仅仅少了0.012%…………
真是可以忽略不计的
不过要说明的是，这是理论计算，在生产实践中，我们使用的很多颜色都是可以用3个字符来表示的颜色，实际上一般来说可能平均起来每个颜色的长度也就是4个字节左右
总之，使用那种类型来保存，还是要根据实际情况来选择的
如果用十进制就是把颜色代码转换成十进制来保存，比如上面的FFFFFF就变成16777215
如果对于这种蓝色 0000FF，其十进制为 256，这样以文本形式传输就只要3个字节，比颜色代码的6个字节要少
对于1000多万种颜色，我算了一下平均每个颜色要多少字节来表示
使用颜色代码就是6字节
使用十进制的话约7.33字节
比直接使用颜色代码大，多出了22.17%
但是，使用十进制进行保存（不是输出为字符串）的时候，只要占用3个字节，也就是2^(3*8)种颜色
其实，如果使用有符号数的话，用十进制可以比颜色代码更短
用有符号数，3字节长的整型有符号变量，范围是-8388608~8388607
这样，如果是正数的话，输出为字符串就只用7个字节，负数才用8个字节，大约比用无符号数的时候少了一半
计算了一下，使用无符号数的话，平均每个颜色值长度是4.59个字节，比颜色代码的6字节少了23.5%
在储存的时候也占用更小的空间
所以，在某些情况下，保存颜色代码用十进制有符号数来表示是比较好的
---------------------------------
更深一步
在新的CSS标准中，对于FF00FF这种颜色，可以简写为F0F，这就减少了代码长度
我计算了一下，这样的话平均颜色代码长度约为5.99927，缩减的量可以忽略……仅仅少了0.012%…………
真是可以忽略不计的
不过要说明的是，这是理论计算，在生产实践中，我们使用的很多颜色都是可以用3个字符来表示的颜色，实际上一般来说可能平均起来每个颜色的长度也就是4个字节左右
总之，使用那种类型来保存，还是要根据实际情况来选择的
修改 DVBBS 7.1 SP2 签名图片高度限制
[ 2006年11月14日 12:41 | by gs ]
2006年11月14日 12:41 | by gs ]
到后台风格界面模板dispbbs(1)
找到
if (obj){
if (obj.offsetHeight>300){
obj.style.overflow='hidden';
obj.style.height='300px';
}
修改成
if (obj){
if (obj.offsetHeight>550){
obj.style.overflow='hidden';
obj.style.height='550px';
}
这样图片高度限制就是500
注意，代码中写的高度要比实际要限制的高度多50px，这多出来的50px是为了显示签名下面的文字，比如“符合XHTML标准”。如果仅仅设置为500的话，当某个图片是500px时，图片下面的文字将无法显示
找到
if (obj){
if (obj.offsetHeight>300){
obj.style.overflow='hidden';
obj.style.height='300px';
}
修改成
if (obj){
if (obj.offsetHeight>550){
obj.style.overflow='hidden';
obj.style.height='550px';
}
这样图片高度限制就是500
注意，代码中写的高度要比实际要限制的高度多50px，这多出来的50px是为了显示签名下面的文字，比如“符合XHTML标准”。如果仅仅设置为500的话，当某个图片是500px时，图片下面的文字将无法显示
FTP与本地文件传输时的经验教训
[ 2006年11月7日 10:13 | by gs ]
2006年11月7日 10:13 | by gs ]
说是经验教训，其实也是软件的Bug，唉……
1、
NTFS大小写问题导致的文件被误覆盖
使用IE进行FTP上传操作，本地的磁盘格式为NTFS，并且设置了文件名区分大小写，服务器上的文件名设置为不区分大小写
远程目录上有一个abc.mdb文件
本地目录上有一个Abc.mdb文件
问题出在这里
如果我们从本地目录上上传一个abc.mdb文件，IE会提示是否覆盖
但是，如果我们上传的是Abc.mdb（注意大小写）的话，IE将不会提示，直接上传该文件。并且上传完毕后还能在远程目录看到Abc.mdb和abc.mdb两个文件
但是实际上，远程目录上只有一个文件，就是刚刚上传上去的Abc.mdb
IE并没有进行提示，就直接覆盖上去了
我就是因为这样，弄丢了一个数据库，哭啊````
2、CuteFTP的文件下载的鬼
CuteFTP（我使用的是CuteFTP 8.x版本）在进行下载文件的时候，如果设置为“如存在同名文件则不提示直接覆盖”的话，CuteFTP将首先删除本地文件，然后才开始下载。这样就出现一个问题。如果远程文件在传输的时候出现错误（实际上不仅限于这种情况，文文末我会说我遇到的那种情况），那么文件无法完全下载完，如果这个时候服务器上的文件正好又出了什么问题的话，那么这个文件就丢失了。有人说可以用EasyRecovery恢复，我遇到这个情况的时候已经马上停止对文件所在磁盘分区的一切操作，并立即使用EasyRecovery尝试恢复，可是，恢复失败，根本没有找到那个文件，天知道CuteFTP是用什么方法删除的。
我遇到的情况是，我上传一个数据库文件，上传到一半的时候，我发现传输停止了，我想是网络的问题，于是停止传输，这时已经把文件的差不多一半上传到服务器上了（看文件大小可知）。我再次尝试上上传，可是总出错，我确定网络没有问题后，看看日志，竟然说“找不到目录”。我倒，那我刷新目录看看，一切正常，目录列表可以出来。然后我再尝试重命名服务器上的上传到了一半的文件，这时提示是“找不到该文件”，我的天啊！！怎么会这样。接下来我就很顺理成章的尝试能不能下载，可是，这回出现的提示是，无法读取文件，我无语……。我想那算了，先不管了，回头来看看本地的那个文件，然而，这时我发现，我的文件找不到了，这时我才想到是CuteFTP在进行文件下载前把它删除了的，可是服务器却无法返回数据流，等于说，本地文件，被删除了……
就这样，又丢了一个数据库。（后来我用服务器上的上传了一半的文件恢复了一半的数据，还算好吧，我再看看以前备份的数据库有没有那部分无法恢复的数据）
两个数据库，两个教训，要牢牢记住啊
1、
NTFS大小写问题导致的文件被误覆盖
使用IE进行FTP上传操作，本地的磁盘格式为NTFS，并且设置了文件名区分大小写，服务器上的文件名设置为不区分大小写
远程目录上有一个abc.mdb文件
本地目录上有一个Abc.mdb文件
问题出在这里
如果我们从本地目录上上传一个abc.mdb文件，IE会提示是否覆盖
但是，如果我们上传的是Abc.mdb（注意大小写）的话，IE将不会提示，直接上传该文件。并且上传完毕后还能在远程目录看到Abc.mdb和abc.mdb两个文件
但是实际上，远程目录上只有一个文件，就是刚刚上传上去的Abc.mdb
IE并没有进行提示，就直接覆盖上去了
我就是因为这样，弄丢了一个数据库，哭啊````
2、CuteFTP的文件下载的鬼
CuteFTP（我使用的是CuteFTP 8.x版本）在进行下载文件的时候，如果设置为“如存在同名文件则不提示直接覆盖”的话，CuteFTP将首先删除本地文件，然后才开始下载。这样就出现一个问题。如果远程文件在传输的时候出现错误（实际上不仅限于这种情况，文文末我会说我遇到的那种情况），那么文件无法完全下载完，如果这个时候服务器上的文件正好又出了什么问题的话，那么这个文件就丢失了。有人说可以用EasyRecovery恢复，我遇到这个情况的时候已经马上停止对文件所在磁盘分区的一切操作，并立即使用EasyRecovery尝试恢复，可是，恢复失败，根本没有找到那个文件，天知道CuteFTP是用什么方法删除的。
我遇到的情况是，我上传一个数据库文件，上传到一半的时候，我发现传输停止了，我想是网络的问题，于是停止传输，这时已经把文件的差不多一半上传到服务器上了（看文件大小可知）。我再次尝试上上传，可是总出错，我确定网络没有问题后，看看日志，竟然说“找不到目录”。我倒，那我刷新目录看看，一切正常，目录列表可以出来。然后我再尝试重命名服务器上的上传到了一半的文件，这时提示是“找不到该文件”，我的天啊！！怎么会这样。接下来我就很顺理成章的尝试能不能下载，可是，这回出现的提示是，无法读取文件，我无语……。我想那算了，先不管了，回头来看看本地的那个文件，然而，这时我发现，我的文件找不到了，这时我才想到是CuteFTP在进行文件下载前把它删除了的，可是服务器却无法返回数据流，等于说，本地文件，被删除了……
就这样，又丢了一个数据库。（后来我用服务器上的上传了一半的文件恢复了一半的数据，还算好吧，我再看看以前备份的数据库有没有那部分无法恢复的数据）
两个数据库，两个教训，要牢牢记住啊
今天一口气把还没有看的零给看完了，呼~~~还算是美好的结局。看完12集我还以为才人真的要回去（貌似应该说回来……）了，让我感觉比AIR还悲伤。
这样说，因为才人可以很熟练的操作此类机械，所以如果飞机有故障的话才人坐上去也应该会知道故障出在哪里，应该如何修复。材料可以用摩法解决，用摩法制造飞机零件应该不成问题。燃料问题也很好解决，那个什么老师一个晚上就能复制出4桶，可见产量还是很高的。接下来是日食，日食是没一两年就会发生一次，虽然不在同一个地方发生，但是有飞机，可以很容易地到达将要发生日食的那个地方。至于日食什么时候发生，也没问题，这个摩法世界已经可以计算出日食发生的时间。最后就是到我们这个世界时的降落问题以及空中管制问题，如果惊动军方的话肯定麻烦大了，所以可以用封属性的摩法进行垂直降落，然后用什么魔法把飞机隐藏起来。接下来，想办法弄到一点我们这个世界的货币，用摩法对其进行复制（才人他们情况特殊，就不要追究法律责任了吧……），然后乘坐我们这个世界的交通工具即可回到日本。
这样，才人和零就可以在我们的世界住一段时间，然后回到魔法世界去一段时间，如此反复。才人既可以回家，零也不会离开家，最重要的是，两人可以永远在一起了。
零和零之使魔，好幸福……
羡慕死……
我的零啊，好想和你在一起
这样说，因为才人可以很熟练的操作此类机械，所以如果飞机有故障的话才人坐上去也应该会知道故障出在哪里，应该如何修复。材料可以用摩法解决，用摩法制造飞机零件应该不成问题。燃料问题也很好解决，那个什么老师一个晚上就能复制出4桶，可见产量还是很高的。接下来是日食，日食是没一两年就会发生一次，虽然不在同一个地方发生，但是有飞机，可以很容易地到达将要发生日食的那个地方。至于日食什么时候发生，也没问题，这个摩法世界已经可以计算出日食发生的时间。最后就是到我们这个世界时的降落问题以及空中管制问题，如果惊动军方的话肯定麻烦大了，所以可以用封属性的摩法进行垂直降落，然后用什么魔法把飞机隐藏起来。接下来，想办法弄到一点我们这个世界的货币，用摩法对其进行复制（才人他们情况特殊，就不要追究法律责任了吧……），然后乘坐我们这个世界的交通工具即可回到日本。
这样，才人和零就可以在我们的世界住一段时间，然后回到魔法世界去一段时间，如此反复。才人既可以回家，零也不会离开家，最重要的是，两人可以永远在一起了。
零和零之使魔，好幸福……
羡慕死……
我的零啊，好想和你在一起
