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

sanalex 发表于 2012-7-25 16:05
我给你个例子：两年前我管理的单台服务器同跑web和mysql、没做raid、主题70w、回帖900w、日pv75w（高峰12 ...

因为我接手迁移时未接管webold服务器（我取名叫old，其实配置比当前使用的服务器还要高），所以不知道系统设置如何，为何性能如此之差。
但是请见这个帖子 https://discuz.dismall.com/thread-2993771-1-1.html 里面同样一个SQL（pg更改了语法不然无法运行），在相同服务器上mysql与pg测试结果。mysql冷查询时间结果差得有点离谱了。那就只有两种原因：
1、mysql烂如狗屎
2、mysql没优化好

至于为啥最大连接要开那么高，如果你看到mysql的慢查询日志就知道了～

mark35 发表于 2012-7-25 16:28
因为我接手迁移时未接管webold服务器（我取名叫old，其实配置比当前使用的服务器还要高），所以不知道系统 ...

o(∩∩)o...
这个里面提出的问题我见过最长的有290+秒，添加个索引就秒查了。
http://dev.discuz.org/doing.php?view=thread&tid=9434

mark35 发表于 2012-7-25 16:28
因为我接手迁移时未接管webold服务器（我取名叫old，其实配置比当前使用的服务器还要高），所以不知道系统 ...

你看看日志就知道该优化哪里了。
慢查询时间设置成1，然后一条一条把它们都解决了就完了。

sanalex 发表于 2012-7-25 16:05
我给你个例子：两年前我管理的单台服务器同跑web和mysql、没做raid、主题70w、回帖900w、日pv75w（高峰12 ...

说实话参数这玩意得你自己慢慢折腾，要不DBA就没人做了。
康盛也并不能去对每个站点都根据情况做优化。

这个是，具体情况有不同的索引调优方案。
只不过mysql的索引机制有够烂，其优化器有时根本无法选择正确高效的索引，甚至不能有效利用索引。还不用说根本不支持函数索引（我在pg改版上使用了函数索引处理会员生日判断，效率极其的高），也不支持部分索引（用于版块内精华主题搜索，效率也是极其的高）

所以就技术上说mysql真没啥可调优的，你也就在mysql.cnf中调整下buff参数吧，可除了buff还有啥可调整的呢？ 如果你打开pg的服务配置文档postgresql.conf, 看看里面可以配置的参数就知道相比于mysql，pg有多么的强大了。在postgresql.conf 里面对于缓存的配置反而很少，也不用所谓调优——只需要根据服务器物理内存按照一定比率设置即可

更多的是关于查询规划器参数的配置，比如表连接方式的开关（hash join, merge join, nested loo, mysql就只支持最后一种），规划器参数因子微调，虽然可以调整的项目很多，但使用默认值也足以让系统保持良好状态。 而并不像mysql那样一个参数没设置好对性能影响可能就巨大，甚至导致服务启动失败 —— 修改下 innodb_data_file_path 就知道了 :p

sanalex 发表于 2012-7-25 16:39
你看看日志就知道该优化哪里了。
慢查询时间设置成1，然后一条一条把它们都解决了就完了。

还1秒啊，当时10秒都快爆了。
你还是看看我发的传送门吧，慢查询日志其中一条SQL，对比测试下都是非常的慢。你看看可有优化之处？

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

我测试那条SQL是threads,posts,attachments三个表作连接，这个根本不能采用简单添加个索引就可以解决的。或者你看看怎么加索引呢

高手啊。神一般的存在。

mark35 发表于 2012-7-25 16:42
我测试那条SQL是threads,posts,attachments三个表作连接，这个似乎不能简单添加个索引就可以解决的。或者 ...

pg强大的地方很多，但是现在discuz可能也用不上，而且还有一个重要的原因是绝大多数虚拟主机不支持，在康盛看来最多也就是考虑下pg。

我很好奇兄弟既然有能力搞定mysql到pgsql的迁移，怎么不抽出点时间搞一搞mysql呢。

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

这个url中SQL语句先不说索引采用，其查询构造就存在问题：

1. 
   
2. SELECT p.authorid, p.tid, p.pid, p.fid, p.invisible, p.dateline, p.message, t.special, t.status, t.subject, t.digest,t.attachment, t.replies, t.views, t.lastposter, t.lastpost, t.displayorder FROM pre_forum_post p
   
3. INNER JOIN pre_forum_thread t ON t.tid=p.tid  AND t.fid IN
   
4.   ('274','80', ....)
   
5. WHERE p.authorid='36661'  AND p.first='0' ORDER BY p.dateline DESC LIMIT 0,20
   

复制代码

左表只有 authorid 和 first 两个过滤条件，结果集可能上万，内层thread无论是否用fid过滤其结果肯定会不会太大，而mysql只支持 nested loop, 在外层结果集比内层大的情况下性能会变差。
所以可以把内层的 fid 条件添加（或者移动）到外层post表上这样就可以极大地提高 nested loop 的效率。