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

mark35 发表于 2012-7-28 18:58
数据库负载和IP没直接关系。只看查询请求并发量。
现在平均每秒500次数据库操作，pg只开了10个左右进程（ ...

每秒500次，在线人数不是达到30万/15分钟？

tearszhu 发表于 2012-7-31 11:28
每秒500次，在线人数不是达到30万/15分钟？

应该没那么高。
用户每次刷新页面平均产生10条SQL查询。每条500条大概折合成50个客户端并发。15分钟计算下来应该约45K。

路过看下，论坛一直没什么流量所以也没有需求。。

bugx 发表于 2012-7-30 16:07
弱不弱可以测试下，我在mysql5.5里测试了1000万数据，count并不是很慢到无法想象的地步。myisam把总数进行 ...

1000万记录， innodb count(*) 估计要数十秒以上。这个时间本身倒不太恐怖，就当是个慢查询。但问题是在这期间会阻塞对表的更新，对于 关联了 threads+posts表的count，这种阻塞带来的后果才是真正的恐怖——无法编辑帖子，主题浏览数无法更新。如果再关联个members表，那就歇菜吧。哈哈～

sanalex 发表于 2012-7-25 20:20
呵呵，你那mysql的描述都哪年的老黄历了

时不时是不只个笼统的说法，还是不负责任的，否则TB、 ...

再说论坛是什么呢，就是个留言板，要ACID做什么呢？myisam本身就不支持这玩意

是啊，论坛就是个留言板，搞这么多功能，搞什么积分、充值、兑换干嘛呢？
什么？会员积分和RMB关联，丢了钱怎么办？ 一个论坛，搞什么ACID搞什么金钱挂钩马……

见识了！！

真是好人啊~~

mark35 发表于 2012-8-6 16:27
1000万记录， innodb count(*) 估计要数十秒以上。这个时间本身倒不太恐怖，就当是个慢查询。但问题是在这 ...

就不能 count(pid)吗？非要count(*)
count(pid)，不会超过3秒。因为post表已经改为myisam，所以我刚才拿 收藏表测试了一下，  6888377  ，600多万收藏。1-2秒左右。

SELECT COUNT( favid )
FROM `pre_home_favorite` ，

这种语句，在PgSQL里也不会很快的，包括MAX这种，都是遍历的。

Transactional databases which implement MVCC such as PostgreSQL and InnoDB perform COUNT(*) in a way that is very slow compared to non-transactional databases like MyISAM. The MyISAM engine in MySQL uses an index scan for COUNT(*) and also caches the result of the count, thus it is much faster. PostgreSQL and InnoDB require a table scan to locate all visible rows. These MVCC capable engines implement COUNT(*) this way because MVCC stores transaction visibility in the row data as opposed to the index. With MVCC capable databases, caching the COUNT(*) would result in incorrect data being returned. PostgreSQL 9.2 will have index-only scan support which uses the visibility map feature to determine whether a row is visible to the current transaction rather than visiting the page. This means dramatically faster COUNT(*) results.

况且这种都是可以做缓存的，根本不是什么性能瓶颈关键所在。这个真不会导致极端的现象。我用innoDB跑dz已经2年了，性能比myisam强大多了。升级2.5后，post表没有办法只能改为myisam。
facebook都有用到mysql，我们这些站长又担心什么。