千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记

附3: 补充笔记 2007-11-17: 关于装有首页四格插件的 dz 论坛导致 MySQL 占用 大量CPU 的分析

　　今天手机巴士的站长( http://bbs.sj84.com )找到我，他的基于 Discuz 的论坛，也存在 CPU 占用 100% 的问题，服务器从 Win 2003 换到　CentOS，内存 2G, CPU 1.86G,　数据：cdb_threads 4 万，cdb_posts 96 万，cdb_members 35 万，已经按我上面文章所说的优化过索引。按说这个配置足够运行论坛了，但问题一直得不到解决。

　　经过调试，将慢查询的结果 dump 到 /usr/local/mysql/var/localhost-slow.log，运行 /usr/local/mysql/bin/mysqldumpslow /usr/local/mysql/var/localhost-slow.log 查看，结合 show processlist 命令，发现慢查询集中在下列语句:

SELECT t.*, f.name FROM cdb_threads t, cdb_forums f WHERE 
t.fid<>'S' 
AND f.fid=t.fid 
AND f.fid NOT IN (N,N,N,N) 
AND t.closed NOT LIKE 'S' 
AND t.replies !=N 
AND t.displayorder>=N 
ORDER BY t.views DESC LIMIT N, N

　　然而搜索 Dizcus 论坛的源码，并没有找到这行代码。怀疑是插件的原因。经查，论坛装了首页四格的插件，这行语句位于 include/toplist.php 中: 仔细检查这行代码，发现存在许多性能或语法规范上的问题：

AND t.closed NOT LIKE 'S':t.closed 是数值字段，不应该用 LIKE 'S' 的形式参与比较。　 ORDER BY t.views: t.views 在 dizcus 的原始数据表中，是没有做索引的。 SELECT t.*: 这种写法，是不被推荐的。如果要选择某个表内的所有字段，最好是按实全部写出来，例如：select t.aa, t.bb, t.cc, t.dd, ... WHERE　t.fid <> 'S': t.fid 是数值型字段，不应该写成 字符比较的形式。这个对性能影响不大，是个编程规范的问题。 ....

　　toplist.php 的其他三条 sql 语句，都存在这些问题。如果要针对他的 sql 语句去优化 MySQL 结构，会带来不良的后果；如果直接改他的 toplist.php 程序，如果站长以后升级　toplist.php 又怕带来不兼容问题。于是我建议他干脆关闭首页四格插件。

　　关闭首页四格插件之后，CPU 降到 18% 左右震荡，表现非常良好。

　　如果是我来写首页四格的程序，我不会采用这种方案，我会用定时15分钟或30分钟查询一次数据库，将结果写入 TXT 文件或临时表，然后程序再从中读取，效率会高许多。

　　结论：

如果装了插件的论坛碰到　CPU 高负荷时，建议关掉插件再评估性能。 慎装第三方插件。没事不要乱插。:)

附4：补充笔记 2008-06-10：这篇文章，重要的是分析过程，而不是进行修正的那段代码

　　最近有几位在评论中留言，以及给我 EMAIL，说到将我在文中给出的 那8行 ALTER TABLE 代码，在他的出现 CPU 100% 的 dz 论坛上，用了之后没有效果。

　　我的解释如下：这段代码，不能保证在 dz 的所有版本下通用。具体问题，要具体分析。这段代码，是我在 Dizcus! 5.5.0 的版本的基本下进行分析得出的校正结果。其他的版本，不敢保证。