上篇传送门：
引发某些mysqler的质疑，因为论坛已经迁移到新系统所以无法以老系统做测试获得对比数据。不过数据都在，我就做个数据库无压力的对比测试吧。
数据来源：
操作系统：CentOS 6.2 X64
mysql版本：mysql-5.1.61-1.el6_2.1.x86_64 （YUM）
pg版本：9.1.4
服务器：web服务器与db服务器配置皆为 DELL 2950III，硬盘前者为SAS RAID5,后者为 SSD RAID，其余硬件配置相同具体可参照上方传送门内帖子。
测试环境：web服务器上mysql/pg皆无外部连接，db 服务器上mysql无外部连接pg为上线论坛正式营运库。营运pg库是最新的数据量要比其余3个库要多，其余三个库内容相同。
测试方式：除了db服务器上pg所有测试都不停机、重启，其余3个数据库先关闭服务30分钟，启动服务器开始第一轮测试，第一轮测试间隔3秒重复测试3次，restart数据库之后重复测试一轮。
测试SQL：来自于dz数据调用的一条实际SQL，此语句在论坛老系统中超时频繁，严重阻塞队列。如图
因为mysql垃圾的GROUP BY功能，此条SQL无法直接运行在pg上面，所以修改如下：
- -- for pg
- SELECT t.tid,t.fid,t.readperm,t.author,t.authorid,t.subject,t.dateline,
- t.lastpost,t.lastposter,t.views,t.replies, t.highlight,t.digest,t.typeid,t.sortid,
- a.remote,a.attachment,a.thumb ,p.message FROM cdb_threads t
- INNER JOIN (
- SELECT t.tid, max(aid) aid FROM cdb_threads t JOIN cdb_attachments a ON a.tid = t.tid
- WHERE t.readperm='0' AND t.fid IN ('87') AND a.readperm = 0 AND a.isimage > 0
- AND a.price = 0 AND t.displayorder>='0' AND t.fid>'0'
- GROUP BY t.tid ORDER BY t.dateline DESC LIMIT 4
- ) a1 ON a1.tid = t.tid
- LEFT JOIN cdb_posts p ON p.tid=t.tid AND p.first='1'
- INNER JOIN cdb_attachments a ON a.tid=t.tid ORDER BY t.dateline DESC
复制代码
测试结果：
1 min 17.48 sec 是啥概念?!
难道测试错了，于是关闭web服务器mysql服务5分钟，启动后重新测试，结果分别是
4 rows in set (2.37 sec)
4 rows in set (1.60 sec)
4 rows in set (0.00 sec)
这好像看起来才正常嘛。也许因为web服务器上面跑着生产的web server以及附件，附件IO读取对mysql影响很大。
为了排除疑点，我重新开始一轮测试，只不过把 SQL中fid的值由87改成12,结果让人吃惊：
难怪一说到mysql慢就会有人说是没优化好，可my.cnf除了buff还有啥可优化的呢？既不能选择连表方式(hashjoin, merge join, neste join) 也不能对查询计划CPU/DISC因子调整。原来mysql就是靠缓存吃饭的啊！而且这个缓存也忒强悍了点吧，我关闭了mysql服务5分钟后缓存依旧存在，要不是第一次是关闭了30分钟还不能确定真有这么慢！
原来都说mysql快，大家也知道是快在myisam上面。可现在活生生的实际测试对比，让我怀疑以前那些测试是怎么做的～
以前如果有人说pg快，那么会对曰那是在高并发下快，普通应用没myisam快。如果有人说myisam不支持事务，没行锁，有对曰innodb支持事务也有行锁。
现在，我真没觉得mysql有什么可以和pg进行抗衡之处。除了可以绿色版安装。
当postgreSQL 9.2版本出来，支持 index-only-scan这个功能后，我不知道mysql在技术上还有什么可值得一用的？
复读机：mysql有myisam，innodb，mem等各种引擎，各有特色。在我看来就实体版的要你命3000 —— 五花八门特色什么功能都有，可没一个称手可堪重任的。 |
