娱乐一下:测试WinRAR与7-Zip压缩比(使用wordpress源码文件及相机照片)

测试环境

软件:采用当前(2019/03/28)的最新x64位版,软件都从官方下载。

  • WinRAR:  v5.70简体中文版      winrar-x64-570sc.exe
  • 7-Zip: 7-Zip 19.00 (2019-02-21) 7z1900-x64.msi

测试素材: 1) WordPress源码解压缩后的文件夹,是 wordpress-3.5.2-zh_CN.zip 比较老,没有特别原因,只是电脑上正好有这个zip包而已。  2) 一批数码相机照片,计400多张,370M.

测试项目

使用WinRAR与7-Zip分别压缩,含标准压缩、最大压缩,压缩成各家独特格式、zip格式,然后比较压缩包大小。

结果

$ ls -l --block-size=K
total 1566840K
drwxrwx---+ 1 feng None      0K Mar 28 17:50 photos

-rwxrwx---+ 1 feng None 377416K Mar 28 17:52 photos_7z19_stand.7z
-rwxrwx---+ 1 feng None 379106K Mar 28 17:51 photos_winrar57_stand.rar

-rwxrwx---+ 1 feng None 377081K Mar 28 17:55 photos_7z19_max.7z
-rwxrwx---+ 1 feng None 379106K Mar 28 17:53 photos_winrar57_max.rar

drwxrwx---+ 1 feng None      0K Jun 22  2013 wordpress

-rwxrwx---+ 1 feng None   6199K Mar 28 17:31 wordpress_winrar57_stand.rar
-rwxrwx---+ 1 feng None   4996K Mar 28 17:19 wordpress_7z19_stand.7z

-rwxrwx---+ 1 feng None   6196K Mar 28 17:45 wordpress_winrar57_max.rar
-rwxrwx---+ 1 feng None   6374K Mar 28 17:58 wordpress_winrar57_max.zip

-rwxrwx---+ 1 feng None   6381K Mar 28 17:58 wordpress_winrar57_stand.zip
-rwxrwx---+ 1 feng None   6337K Mar 28 18:00 wordpress_7z19_stand.zip

-rwxrwx---+ 1 feng None   4969K Mar 28 18:02 wordpress_7z19_max.7z
-rwxrwx---+ 1 feng None   6292K Mar 28 17:57 wordpress_7z19_max.zip

-rwxrwx---+ 1 feng None   6172K Mar 28 17:19 wordpress_winrar371_stand.rar

[注] 为方便对照,调整了条目的次序,并非ls原始次序。

简评

从结果上看,所有测试项目都是7-Zip胜出,这在意料之中。但同样压缩成zip格式,7-Zip都好于WinRAR.

甚至,winrar 3.71版比 5.70版压缩率还更高!实在让人大跌眼镜!

ms sql在对大表做很慢的更新语句时,应单条处理,而不要一个语句更新多条,以避免锁表而阻塞其它应用的读操作

接到一客户的要求,需要修改其发布过所有文章里的联系方式,于是写sql语句,拿到mssql客户端里直接执行。

起初写的是这种形式的语句
update article set [content]=replace(content,'aaaa','bbbb') where companyid=123
写起来很简单,但是执行时花了3分钟都没有执行完,在执行过程中,网站上对article表访问的页面全部长时间没有响应。于是赶快停掉这个update语句。前面页面马上恢复正常。

分析原因应该是在update时,表被锁定,而阻塞了所有操作。
于是改成
update article set [content]=replace(content,'aaaa','bbbb') where id in(111,222,333,444....)
这种形式,当然首先要查出该客户的所有文章id号,再用逗号拼接构造成sql语句。
这个语句执行一样很慢,可以想象;试了试前台页面又没不响应了。于是赶快停掉。
要重新修改语句。
这次改成
update article set [content]=replace(content,'aaaa','bbbb') where id =111
update article set [content]=replace(content,'aaaa','bbbb') where id =222
update article set [content]=replace(content,'aaaa','bbbb') where id =222
update article set [content]=replace(content,'aaaa','bbbb') where id =222
....
这种多语句的形式,有4K多条,复制到mssql客户端里执行,还是很慢,但前台页面都可以正常打开了,根本感觉不到正在执行的update语句的影响。
经过5分多钟,终于执行完成。

上文中的语句是作了简化的,实际上构造出来的语句是这个形式
update [article] set [content]=replace(replace(replace(replace(convert(nvarchar(max),[content]),'f***','y***'),'1376133***','1358571***'),'353***','605***'),'354***','606***') where id=23002
其中,content字段是ntext型,还得convert();原来数据库是mssql 2000,后来升级到2005,本来应该把字段改成nvarchar(max)型,但因为表太大一直没有改。

查出id号作逗号拼接,是使用uestudio的替换功能,相当方便