Discuz能有多快？ 见识下postgreSQL的强悍，对比下mysql的低能

sanalex 发表于 2012-7-25 16:55
pg强大的地方很多，但是现在discuz可能也用不上，而且还有一个重要的原因是绝大多数虚拟主机不支持，在康 ...

说实话，我是从mysql入手的。开始觉得它好得不得了。后来接触了pg之后才发现自己就是那只井底之蛙～
mysql与pg相比根本不是一个级别的，不标准的地方不少，它只能算是个玩具。 所以现在对mysql没啥兴趣，或者说mysql没有啥可供我有热情折腾的，有部分索引么，有函数索引么，有分区表么，有sequece么 ～

在移植过程中最痛恨mysql的有两处：
1、GROUP BY
2、last_insert_id()

现在开发的项目都尽量避免使用mysql，用pg至少我不会担心表损坏。

sanalex 发表于 2012-7-25 16:37
o(∩∩)o...
这个里面提出的问题我见过最长的有290+秒，添加个索引就秒查了。
http://dev.discuz.org/d ...

秒查，呵呵。你也许没见过pg快到以毫秒为单位的，而且条件相当复杂。 并且pg的FTS更加强悍，你到 www.ifxtx.com 上去搜索下 用户名，主题标题（或者两者的组合），其速度是极速。

你用过dz后台的【待处理事项 】吧，有多少站长因为打开 待审核主题/回帖 连接极其缓慢而放弃使用此功能了呢。我这儿瞬间就进入了

mark35 发表于 2012-7-25 16:55
这个url中SQL语句先不说索引采用，其查询构造就存在问题：左表只有 authorid 和 first 两个过滤条件，结果 ...

呵呵，不要怀疑，这个问题只在pre_forum_post上添加一个索引就可以了。

在我的测试机上有5.49秒，但是在生产环境下只有0.03秒，加索引之前的时间就不说了惨不忍睹。
测试机主要搞innodb，myisam参数开的很低，论坛样本的主题数有108w，回帖数有接近2900w。

mark35 发表于 2012-7-25 17:05
秒查，呵呵。你也许没见过pg快到以毫秒为单位的，而且条件相当复杂。 并且pg的FTS更加强悍，你到 www.ifx ...

呵呵，0.03秒问觉得也挺慢了，pg再强大也不是说mysql是狗屎的理由XD

有多少人的站点建立在虚拟主机上不能动mysql的配置呢，也是相当多的。

sanalex 发表于 2012-7-25 17:20
呵呵，0.03秒问觉得也挺慢了，pg再强大也不是说mysql是狗屎的理由XD

有多少人的站点建立在虚拟主机上不 ...

我在说书，允许夸张点嘛～

sanalex 发表于 2012-7-25 17:20
呵呵，0.03秒问觉得也挺慢了，pg再强大也不是说mysql是狗屎的理由XD

有多少人的站点建立在虚拟主机上不 ...

不过我那个对比测试中，我实在无法理解为何关闭了mysql服务短期内其缓存结果居然还可以下次利用，非得停止半小时才能完全消除。

sanalex 发表于 2012-7-25 17:20
呵呵，0.03秒问觉得也挺慢了，pg再强大也不是说mysql是狗屎的理由XD

有多少人的站点建立在虚拟主机上不 ...

有多少人的站点建立在虚拟主机上不能动mysql的配置呢，也是相当多的。

这种网站数据量不会大，数据也不会有啥价值……

mark35 发表于 2012-7-25 17:39
不过我那个对比测试中，我实在无法理解为何关闭了mysql服务短期内其缓存结果居然还可以下次利用，非得停止 ...

可能buffer还在内存吧。

mysql不是那么脆的，女人不穿好看的衣服不会好看嘛，mysql的参数、索引和web程序都是衣服和饰品，看怎么搭配

sanalex 发表于 2012-7-25 17:47
可能buffer还在内存吧。

mysql不是那么脆的，女人不穿好看的衣服不会好看嘛，mysql的参数、索引和web程 ...

mysql进程已经结束了，下次启动还能利用上次的缓存？ pg测试中没发现（明显）有这种情况。

mark35 发表于 2012-7-25 18:07
mysql进程已经结束了，下次启动还能利用上次的缓存？ pg测试中没发现（明显）有这种情况。

如果是innodb的buffer，还可以通过设置，在进程挂掉的情况下通过内存进行数据修复，当然系统挂了就没办法了。

要是在buffer吃掉全部数据的情况下，呵呵。。。