为什么玩抢滩登陆2002，cpu竟然飙到100？？下面附上硬件配置。_百度知道
提问者采纳
抢滩2002，他真的没见过win7系统，都是兼容运行的，很有可能有bug。不过就是一直满载的话，CPU也不至于穿法扁盒壮谷憋贪铂楷过热关机的。应该是该除尘了。正常情况就是满载运行24小时也不应该有问题的。
应该不是bug问题，我换了几个网站下过了一样的问题。而且我玩极品9都无事呢~~为什么呢？如果满载太久，正常来说CPU就会大量发热，然后就会cpu就会启动过热保护自动断电的哇！！怎样可以满载运行24小时啊？
有专门的拷机软件，只要开着，cpu一直是满载的。你的散热器要是原装的话，还是建议你换一个吧。还是专业的好用。
提问者评价
谢谢你的解答……我对这个抢滩2002失望了
其他类似问题
抢滩登陆的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记 - 程序员小辉
千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记
　　注：本文最后更新于：
　　2007年3月，我写过一篇文章《》(
)，谈到自己在解决一个拥有 60 万条记录的
数据库访问时，导致 MySQL CPU 占用 100% 的经过。在解决问题完成优化(optimize)之后，我发现 也存在这个问题，当时稍微提了一下：
发现此主机运行了几个 Discuz 的论坛程序， Discuz论坛的好几个表也存在着这个问题。于是顺手一并解决，cpu占用再次降下来了。
　　前几天，一位朋友通过这篇文章找到了我，说他就是运行最新的 discuz 版本，MySQL 占用 CPU 100%，导致系统假死，每天都要重启好几次，花了一个多月的时间一直没有解决，希望我帮忙一下。经过检查，他的这个论坛最重要的几个表中，目前 cdb_members 表，有记录 6.2 万；cdb_threads 表，有记录 11万；cdb_posts表，有记录 1740 万；所有数据表的记录加起来，超过 2000 万；数据库的大小超过 1GB。经过半天的调试，总算完成了 discuz 论坛优化，于是将其解决经过记录在这篇文章
　　2007年3月我发现 discuz 论坛的数据库结构设计有一些疏忽，有许多查询子句的条件比较，都没有建立 Index 索引。当时我所检查的那个数据表，记录只有几千条，因此对 CPU 负荷不大。现在这个数据库表，上千万的记录检索，可以想象，如果数据表结构设计不规范，没有提供索引，所耗费的时间是一个恐怖的数字。有关 MySQL 建立索引的重要性，可以参见我的这篇文章底部的说明：
　　为了调试方便，我从 dizcus 的官网下载了其最新的 Dizcus! 5.5.0 论坛程序．
　　我首先检查了 my.ini 的参数配置，一切正常。进入 MySQL 的命令行，调用 show processlist 语句，查找负荷最重的 SQL 语句，结合 Discuz 论坛的源码，发现有以下语句导致 CPU 上升：
+-----+------+----------------+---------+---------+------+------------+---------
-----------------------------------------------------------------+
| User | Host
| Command | Time | State
+-----+------+----------------+---------+---------+------+------------+---------
-----------------------------------------------------------------+
| 363 | root | localhost:1393 | history | Query
0 | statistics | SELECT C
OUNT(*) FROM cdb_pms WHERE msgfromid=11212 AND folder='outbox' |
+-----+------+----------------+---------+---------+------+------------+---------
　　检查 cdb_pms 表的结构：
mysql> show columns from cdb_
+-----------+------------------------+------+-----+---------+----------------+
| Null | Key | Default | Extra
+-----------+------------------------+------+-----+---------+----------------+
| int(10) unsigned
| PRI | NULL
| auto_increment |
| varchar(15)
| msgfromid | mediumint(8) unsigned
| mediumint(8) unsigned
| enum('inbox','outbox') | NO
| tinyint(1)
| varchar(75)
| dateline
| int(10) unsigned
| delstatus | tinyint(1) unsigned
+-----------+------------------------+------+-----+---------+----------------+
10 rows in set (0.00 sec)
　　这条语句: WHERE msgfromid=11212 AND folder='outbox'，我们看到，在 cdb_pms 表中，msgfromid 字段已经建立了索引，但是，folder 字段并没有。目前这个表已经有记录 7823 条。显然，这会对查询造成一定影响。于是为其建立索引：
mysql> ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
Query OK, 7823 rows affected (1.05 sec)
Records: 7823
Duplicates: 0
Warnings: 0
　　继续检查：
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
| User | Host
| Command | Time | State
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
| 1583 | root | localhost:2616 | history | Query
0 | statistics | SELECT
t.tid, t.closed, f.*, ff.*
, f.fid AS fid
FROM cdb_threads t
INNER JOIN cdb_forums f |
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
1 rows in set (0.00 sec)
　　这条 SQL 语句是针对最重要的数据表 cdb_threads 进行操作的，由于 show processlist 没有将这条 SQL 语句全部显示完全，经对比 Discuz 论坛的源码，此SQL语句的原型位于 common.inc.php 的 Line 283，内容如下：
$query = $db->query("SELECT t.tid, t.closed,".(defined('SQL_ADD_THREAD') ?
SQL_ADD_THREAD : '')." f.*, ff.* $accessadd1 $modadd1, f.fid AS fid
FROM {$tablepre}threads t
INNER JOIN {$tablepre}forums f ON f.fid=t.fid
LEFT JOIN {$tablepre}forumfields ff ON ff.fid=f.fid $accessadd2 $modadd2
WHERE t.tid='$tid'".($auditstatuson ? '' : " AND t.displayorder>=0")." LIMIT 1");
　　经检查，数据表 cdb_threads, 并没有针对 displayorder 字段建立索引。在 discuz 论坛中，displayorder字段多次参与了 Where 子句的比较。于是为其建立索引：
mysql> ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
Query OK, 110330 rows affected (2.36 sec)
Records: 110330
Duplicates: 0
Warnings: 0
　　此时 cpu 已经轻微下降了一部分。
　　继续检查，发现 下面这条 discuz 的 SQL 语句，也导致负荷增加，这条语句位于 rss.php 程序中的第 142 行。
$query = $db->query("SELECT t.tid, t.readperm, t.price, t.author, t.dateline, t.subject, p.message
FROM {$tablepre}threads t
LEFT JOIN {$tablepre}posts p ON p.tid=t.tid AND p.first=1
WHERE t.fid='$fid' AND t.displayorder>=0
ORDER BY t.dateline DESC LIMIT $num");
　　在这个 Order by 子句中，用到了 cdb_threads 表中的 dataline 字段。这个字段是用来存储 unixtime 的时间戳，在整个论坛程序中，大部分时候数据的排序也是基于这个字段，竟然没有建立索引。于是加上：
mysql> ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
Query OK, 110330 rows affected (12.27 sec)
Records: 110330
Duplicates: 0
Warnings: 0
　　查找占用 CPU 高负茶的 SQL 语句，是一件麻烦而又枯燥的事，需要一条一条排除、分析。后面的工作，都是依此类推，经过检查，共查出有八处地方，需要增加索引，如果你也碰到了 discuz 5.5.0 论坛导致 cpu 占用 100% 的情况，可以直接将下列语句复制过去，在 mysql 的命令行下执行即可：
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );
　　注意：“cdb_” 是 discuz 论坛的默认数据表前缀。如果你的表名前缀不是 “cdb_”，则应该改成你对应的表名。例如：my_threads, my_pms 等等。
　　完成这些结构的优化之后，整个系统的 CPU 负荷在 10%~20%左右震荡，问题解决。
　　我很奇怪，设计数据库结构，是一个数据库开发人员的基本功，discuz 论坛好歹也是一个发展了有六七年的论坛了，为何数据库结构设计得如此糟糕？我想也许有如下三个原因：
数据库开发人员设计时本身的疏忽
故意留下的缺陷，当普通论坛没有上数量级的记录时，不会感觉到这个问题，当数据量增大（例如千万级），此问题突现，以便针对用户提供个性服务收取服务费．呵呵，估且以最大的恶意来猜测此事，玩笑而已，不必当真。:)　
另一个可能就是用户的论坛是从低版本升级而来，程序升了级，但数据结构也许没有做相应的更新
附1: 补充笔记
　　今天查看网站日志的 reffer, 发现在 discuz 的官方论坛上，有人就此文引起了一些争论: 。discuz 的管理员和管理员有如下言论：
引用自 cnteacher:
恰恰相反，discuz 的优化措施和数据库的索引是按照大规模论坛设计的。
TO 一楼：数据库结构的设计都是按照程序应用来进行的，使用任何非Discuz! 标准版本以外的代码和程序，或者变更标准数据结构，均可能遇到不可预知的各种问题。
引用自 童虎:
你们可以看看xxxxx, xxxx之类的比较大型的网站，这种网站使用dz论坛都没有问题，说明dz标准程序是没有问题，出现楼主说的情况，多半属于服务器或者安装一些插件造成的
　　显然将问题推给插件的原因是不正确的．举个简单的例子：在最新的 discuz 5.5.0
forumdisplay.php 第183 行，有如下语句：
$query = $db->query("SELECT uid, groupid, username, invisible,
lastactivity, action FROM {$tablepre}sessions
WHERE $guestwhere fid='$fid' AND invisible=0");
　　这里的 invisible 并没有建立索引。本文中有评论认为 session 表是内存表, 速度会很快。理论是如此。不过我在 show processlist 中，观察到上面这条语句占用了大量 CPU， 所以也将其一并加上了 index。cdb_threads 中的 closed 等字段, 也多次参与 where 运算, 也没有建立索引。这些运算的语句, 是 discuz 自己的程序中的。
附2: 补充笔记
　　自从这篇笔记发表以来，在我的这篇文章的评论、以及我的联系消息中，就经常收到许多下面两种类型的评论和邮件：一、许多技术人员批评我胡说八道、Dizcus 论坛不需要做优化或者不能乱建索引的；二、许多使用Dizcus
的站长找我“冰天雪地裸体跪求”解决他们的 CPU 占用 100% 的问题。
　　一、关于 MySQL 数据库优化技术上的争论，我的观点再次声明如下：
技术上的争论是可以放开了讨论的。而我的水平也确实只是半瓶水，对数据库的理论知识也只懂这么点，牛牛们的批评，我虚心接心，非常感谢。但是，评论里的批评不要上升到人身攻击，否则，我的地盘我作主，直接删除。
数据库的优化，要涉及到的方方面面很多。关说理论是没有用的，得靠事实说话。一个千万级数据库的实例优化说明不了问题，两个千万级的数据库优化也许还说明不了问题，但我相信，三个、四个、五个总是可以说明问题的，－－截止到 ，我已经帮助朋友优化过五个记录数超过 1000 万的 discuz 论坛了。我想事实胜于雄辩：优化之前，cpu 都是 100%；优化之后，cpu 降到 30%~40% 左右。没错，做 ADD INDEX　会增加数据库 INSERT/UPDATE 时的开销，但别忘了论坛最主要的操作，是 SELECT 查询。
　　二、关于找我帮忙解决数据库优化的评论和邮件，答复如下:
数据库的优化，不同的版本有不同的实际情况，优化一个 database，短则三两小时，慢则两三天。我的精力有限，不可能一一帮到。
对于没有收入的个人网站，我可以在月末的空余时间帮忙。请事先与我联系好。
对于有收入的网站，请带价格与我联系，或者直接安排美女请我吃饭，否则免谈。:) 请不要来信问“优化我们这个论坛你要多少费用？”这样没营养的话，请直接说“帮我们优化 XXXX 网站或论坛， XXXX RMB 可以不？”，我觉得合适就会回复你。大家都很忙。
邮件与我联系。不要在评论里留个 QQ 号然后要我加你，我不会时时看评论。
附3: 补充笔记 : 关于装有首页四格插件的 dz 论坛导致 MySQL 占用 大量CPU 的分析
　　今天手机巴士的站长(
)找到我，他的基于 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
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：补充笔记 ：这篇文章，重要的是分析过程，而不是进行修正的那段代码
　　最近有几位在评论中留言，以及给我 EMAIL，说到将我在文中给出的 那8行 ALTER TABLE 代码，在他的出现 CPU 100% 的 dz 论坛上，用了之后没有效果。
　　我的解释如下：这段代码，不能保证在 dz 的所有版本下通用。具体问题，要具体分析。这段代码，是我在
Dizcus! 5.5.0 的版本的基本下进行分析得出的校正结果。其他的版本，不敢保证。
　　这篇文章的重点，并不是作为结果的这段代码，而是如何得出这个结果的分析过程。知道了原理，你自己一样可以分析。
附5: 相关文章：
第 1 楼& hcy1122 发表于
支持你，小辉！
我们要继续努力
你现在在哪呢？好久没有你写关于自己的随笔了
XiaoHui 回复于
02:06 : 在长沙．：）
第 2 楼& 游客 发表于
索引不是越多越好，建立了索引之后，插入更新速度就是非常慢，只是select能比较快，这两者之间要有一个均衡点
第 3 楼& pzhai 发表于
估计discuz!越来越看重中小论坛的市场了吧 ，再说本来mysql对海量数据就不太友好，发展瓶颈吧
第 4 楼& vagabond 发表于
写不得不错啊，大哥现在从事什么工作
程序员出来都了什么工作
第 5 楼& 继续革命 发表于
$query = $db-&query(&SELECT uid, groupid, username, invisible,
lastactivity, action FROM {$tablepre}sessions
WHERE $guestwhere fid='$fid' AND invisible=0&);
session 表为内存表，且定长，且频繁写入，且行数较少，在不建立的索引的情况下速度亦十分之快，建立过多的索引，反而会降低写入和更新的效率。楼主的网站如果在线人数达到1w，你再看是什么效果？
XiaoHui 回复于
23:06 : 多谢指正. 抱歉, 我没有注意到 session 表是内存表. 我在 show processlist 观察到这条语句占用 cpu 比较频繁, 加上 index 之后, 效果有改善. 当然, 有更多的例子, 例如 cdb_threads 的 closed 字段, dataline 字段等.
一个事实是: 在添加了这些 INDEX 之后, 目标主机的 CPU 由100% 降到了 10~20%. 另外声明一下, 文中所说的主机不是我的, 我只是帮朋友处理一下.:)
第 6 楼& mad_frog 发表于
discuz的这些所谓的优化，有些是不错的比如dateline的问题，但是你也应该知道如此（上千万级）数量的数据，做不做这样的索引优化，是有实际条件的，数据更新的频繁度导致了他们不敢这么做索引，这是论坛呀，不是文章管理系统。更新的占多数。
第 7 楼& Rocky_Li 发表于
小辉加油！我看好你！
第 8 楼& rq 发表于
小辉，我认为discuz没有这么多所谓的索引问题
优化千万级数据量的数据库最好是在硬件上下功夫，例如加大内存，使用SCSI磁盘阵列，或者直接使用多服务器负载均衡。
另外说说索引：
大多文中提到没有建立的索引其实都在复合索引中，是和查询语句相匹配的
例如：cdb_pms表中有msgfromid索引（msgfromid+folder+dateline），就对应WHERE msgfromid=11212 AND folder='outbox' ORDER BY dateline DESC这个查询，在多条件的查询中，复合索引命中率会比较高，效率要比单独建立msgfromid,folder,dateline三个索引效果好，并且节省资源。
同样cdb_thread的displayorder,closed也不必单独再建立索引，因为在文中提到的查询条件中tid已经是聚集+唯一索引，数据库查询优化器不会因为后面的条件受影响的：）
discuz在索引的设置上我认为是合理的。
索引加速了读取速度，但是也降低了写入和更新的速度，我认为索引要用到频繁读取的地方，例如帖子列表/帖子内容这样的地方。在小辉提到的2kw级别的bbs，在线人数/发帖回帖量都是一个比较大的规模，所以使用索引的平衡点更加重要。
100%资源占用造成的问题我想是因为mod使用不当，例如今日发帖排行、今日新帖、今日热帖一类的功能，这些查询才是罪魁祸首，小辉可以试试去掉所有插件后CPU还是不是这么高。
XiaoHui 回复于
11:34 : 多谢批评指正. 复合索引这块我了解.
我后来查看了一下, 造成这个现象, 有两个原因:
1. 用户升级论坛程序之后, 没有升级数据表的结构. 新近的程序, 采用的数据表结构也不一样, 索引也不一样. 用户没有升级这块, 所以造成查询耗时. 这个原因, 是由于我在查看用户实际的数据表结构与 discuz 最新安装程序的 install SQL 时发现的.
2. discuz 本身有部分没有考虑到索引的问题. 这个我在查看最新的 discuz 论坛源码以及 install SQL 源码时, 得到的验证.
但总的来说, 以第一条原因居多. 所以我在文中对 discuz 的指责, 确实有些过于偏激. 在此愿意表示道歉.
索引的滥加确实会造成写入和更新的速度. 但我觉得这篇文章里提到的更改方式, 应该是正确的. 毕竟有一个看得见的 2kw 记录实际解决效果在这里.
第 9 楼& iamxyh 发表于
支持小辉的观点,不管理论怎么好,要看实际效果嘛.
第 10 楼& shenlag 发表于
小辉的这两篇文章都认真的学习了！对MYSQL很不懂！
我这边也是这样的问题，MYSQL占用服务器CPU很大！！POSTS表数据是20万！搞的论坛上到处都有人抱怨速度太慢！很郁闷！
看到下边的几个回复，也不敢擅自改了！我该怎么办？还请小辉能帮下忙！留个QQ好吗？或是直接加我：，希望小辉能在百忙中帮下我的忙！很着急
XiaoHui 回复于
23:52 : 你先确认是一下，是不是 MYSQL 导致的 CPU 占 100%. 具体可以进入任务管理器，查看 mysqld-nt.exe 或 mysql.exe 这个进程占用 CPU 的情况. 如果确实是它，你再找我。否则我也不能担保解决问题。
第 11 楼& 秋秋 发表于
现在是晚上11点，看到你的主页，你的一些照片和你的自传经历，感觉很敬佩你……
当然，进入你主页的原因是从dz那边看到有朋友推介你的一篇文章：千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记
我看了之后，觉得你说的很对，虽然我不知道你在说什么，但我知道你应该能帮助到我……
呃……我的论坛，现在好像很慢，不知道是不是mysql的原因
如果你用空的话，能加我一下么，指导一下，感激不尽……
我的qq:156994
非常感谢，祝你的程序员之路越走越远，你的理想也早日实现！
o(∩_∩)o...
XiaoHui 回复于
23:48 : 你先照我的文章看对照看一下。另外，查看一下任务管理器，你的 MYSQLD-NT.EXE　的程序，占用CPU是否极高。如果不是，则不是 MYSQL　的原因了。
第 12 楼& 陆林 发表于
dizcus 的论坛网络上有这么多人用，有问题他们自己开发者难道不会解决？数据都是有缓存的，关索引屁事啊。
第 13 楼& 时空论坛 发表于
刚才逛 dizcus 官网，发现有人在争论小辉的这篇文章，从那边点过来的。呵呵，原来这里也这么热闹。
第１２楼的，我的网站也用是的 dizcus 的论坛，数据记录有 1300千万条，月初找到小辉，正好他有空，一个多小时就帮我解决了。事实胜于雄辩，有些东西，需要海量数据是验证的。一般的小数据量也许说明不了问题。
第 14 楼& cn256 发表于
你好，我想问下，除了DZ出现此问题外，我的站主要是SS出现MYSQl占CPU 100%的问题，有没有SS的解决办法？谢谢。
XiaoHui 回复于
13:48 : SS 是什么？
第 15 楼& cn256 发表于
SS就是SupeSite/X-Space，在DZ官方论坛有专栏的。
数据库也是用MYSQL，我的站经常因这样被DOWN，很是郁闷，希望能得到你的帮助，谢谢！
祝你工作顺利，身体健康，全家幸福！
XiaoHui 回复于
13:49 : 如果确定是 MYSQL　占用的额度高，你可以进入本站的 个人消息中心( /msg/ )与我联系。我周六可以帮你看看。
第 16 楼& 秋秋 发表于
你好，小辉
我看了你关于w3wp占用百分百的问题
解决办法，是让执行那些语句
我是想问，执行，是在PHPMYADMIN里执行，还是dz论坛后台执行啊，迫切的需要解决，谢谢你
我qq“156994
我的MYSQLD-NT.EXE程序占用百分之3左右 谢谢
XiaoHui 回复于
21:28 : 你可以在 MySQL 的命令行　或 phpmyadmin 下执行。
第 17 楼& 秋秋 发表于
谢谢小辉的回答，我没有装phpmyadmin 也不会安装，在mysql的命令行下执行，我也听不懂，不过，我问下简单的，就是，dz后台有数据库升级。可以填写命令，然后提交，请问，这个可以么？
再次感谢小辉~
XiaoHui 回复于
19:35 : 我没有用过DZ最新版本中支持后台数据库升级的模块。如果它可以执行 SQL　命令，按理说是可以的。但我不能给你打包票，需要你自己测试一下。并且，为了数据安全，做之前最好将数据库做备份。
第 18 楼& 秋秋 发表于
谢谢小辉，可是，我不太敢试，你什么时候有空，能帮帮我么，小辉，拜托了，我的qq:
第 19 楼& bambo 发表于
以前就看过你的前一篇文章,也在收藏栏里收藏了,今天在DZ看到链接又来看了.
也有人用DZ出现这样的问题,我都会推荐让他来看你的博客,支持你一下.
第 20 楼& 027bbs 发表于
我新换的服务器也出现启动数据库CPU就占用100%的情况,有时间帮忙看下吗?一定感谢
第 21 楼& xyz 发表于
我的现象是w3wp.exe大概每隔20分钟突然占用内存升高到几百m，导致内存耗尽应用程序池自动回收，这时网站无法访问，等几分钟回收后又会正常。
第 22 楼& billee 发表于
我也有同的问题，但我不会改
可否帮忙下？也是Mysql+PHP的
在线才百来个人就占用100%的CPU资源
QQ：3074303 商量一下，呵呵
第 23 楼& 6677875 发表于
非常支持你，我的论坛也有问题是否有时间帮我看一下！付费也可以
第 24 楼& bizzx 发表于
discuz 1500000个用户时，用户列表翻页数度极其慢，有办法解决吗？支持楼主一下
XiaoHui 回复于
16:06 : 我没有研究过这个问题。如果你有慢查询的日志记录，问题肯定是可以能分析出来并解决的。如果无法解决，那就应该属于人品问题了。
第 25 楼& 建站铺 发表于
第 26 楼& 精致生活 发表于
DZ5.5的站，运行一年，近几天发现posts表的record竟有38891条，而网站贴子38800条左右，请问一下小辉这属正常吗？谢谢！
XiaoHui 回复于
09:37 : 这种情况, 有点数据冗余，是正常的。造成情况，一般因为删除主题时，论坛程序只删除了 主题数据（thread)，而忘了删除 posts 中的数据。不会影响论坛的正常运行。
第 27 楼& Ray 发表于
你好,最近我也遇到相关问题,请问DZ6.0还需要你谈及的
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );
第 28 楼& cocockle 发表于
你好,我现在也出现此类问题@
动不动就出现s u情况!
我现在的是6.1
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );
或者帮我处理一下,我的QQ:
XiaoHui 回复于
13:16 : 不能保证通用。具体问题，要具体分析。这段代码，是以
Dizcus! 5.5.0 的版本进行的校正。其他的版本，不敢保证。
这篇文章的重点，并不是作为结果的这段代码的，而是如何得出这个结果的分析过程。知道了原理，你自己一样可以分析。
第 29 楼& sudu8 发表于
一台服务器上有数个MYSQL数据库 现在MYSQL有时候会占很高CPU 请问如何能查出是哪个数据库占的CPU？感谢指教
XiaoHui 回复于
11:06 : 在 MYSQL SHELL　下执行
或 在 my.ini 中，　配置 log-slow-queries= xxxxx.log 然后再分析.
第 30 楼& ff 发表于
第一次见到这么做索引的...建议作者再去学习一下Mysql如何调用索引.
一个SQL查询MySQL只会从一个索引查询，最基本的道理都不懂么？
这么搞索引，会让IO负载无限增大的
第 31 楼& 支持 发表于
第 32 楼& henry 发表于
请教楼主,我安装discuz6.1时-服务器环境(apache2.0+php5.26+Zend Optimizer+mysql5.0),数据库在本机,论坛安装后速度挺快0.0几秒可显示页面,不过数据库远程时,论坛的访问速度慢很多,要4秒以上.
请问楼主有没有分布式部署的一些教程和解决方案,多谢了.
XiaoHui 回复于
20:44 : 最好布署在同一机房比较好，速度应该没这么慢。抱歉的是，我分布式部署对这块没有详细了解。你可以了解一下这些知识点看看 MySQL 的主从复制 MySQL-Proxy 以及 MySQL 5.1 分区
第 33 楼& henry 发表于
谢谢楼主的回答,支持你!
第 34 楼& 风云在起 发表于
楼主,您好, 请教问题，Discuz 对 mysql 数据库释放的代码 是怎样处理的呢?我看了DZ代码 找了好久,都没看到哪里用到 close 函数来关闭数据库连接 望指教
XiaoHui 回复于
20:30 : 这个我没注意过. 手上没DZ的源码. 你自己再细看看.
第 35 楼& 海量数据处理 发表于
辉兄。。。 能不写个上面Mysql语句的反向安装
我不小心按错数据库了。。
XiaoHui 回复于
11:09 : 没太听懂你的意思。装错数据库了，可以再移出来就是了啊。
第 36 楼& 海量数据处理 发表于
不是啊，辉兄，我对Mysql的理解还处于婴儿时期，看了你的文章，就运行了
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
可是我运行的数据库不是安装discuz论坛的那个数据库,,, 但我又不会手动删除操作Mysql, 所以裸体跪求反安装，是不是把ADD改成delete就行了?
ALTER TABLE `cdb_pms` delete INDEX ( `folder` );
XiaoHui 回复于
17:07 : 还是没懂你的意思。不敢给你意见。:)　
你若是要删除 INDEX，　用
DROP，不是 DELETE
第 37 楼& 笑容 发表于
建议把加减法改到10以内，大了不会算。
另外表扬下你的耐心，这么耐心去哄他们，真厉害哈。
一个千万级的黄页网站，正在捣鼓优化问题呢。呵呵
XiaoHui 回复于
17:02 : 呵呵，这个加法应该很好算的， 我设计的是　(1 ~ 9 ) + ( 10 ~ 19)　＝　？
这个范围，应该不需要借助计算器，我女儿都会算了。:)
第 38 楼& test 发表于
授人以鱼，不如授人以渔。
能看多些实际操作文章更好。
目前只是通过增加INDEX来加快查询速度，不知道还有没有更多其它的方法。
例如，使用WHERE语句时要注意什么。
LIKE如何写才规范。
LEFT JOIN 语句 多表联动查询，要注意什么。
内存表的深入应用。。。。。等等。。。。
第 39 楼& tatacom 发表于
80W主题的论坛, 用户访问翻页占CPU很厉害, 请问有没有什么好的解决办法?
慢查询日志里很多这样的
# Query_time: 6
Lock_time: 0
Rows_sent: 38
Rows_examined: 33892
SELECT t.* FROM cdb_threads t
WHERE t.fid='58'
AND t.displayorder IN (0, 1)
ORDER BY t.displayorder DESC, t.dateline DESC
LIMIT 101, 38;
# Query_time: 6
Lock_time: 0
Rows_sent: 38
Rows_examined: 51837
SELECT t.* FROM cdb_threads t
WHERE t.fid='25'
AND t.displayorder IN (0, 1)
ORDER BY t.displayorder DESC, t.dateline DESC
LIMIT 25637, 38;
第 40 楼& 王子 发表于
不错的东西哦，谢谢分享
第 41 楼& 灵格王子 发表于
我的 discuz 论坛也是遇到了 CPU 100% 的问题，在 discuz 的官网里发贴反映了两个多月，给康盛也打了电话无数，一直没有解决。我搜遍了整个网络，本来不抱希望地找到了小辉。没想到他很快就帮我找到了问题症结并解决，我要给他辛苦费也不收。
在此特别表示感谢！
第 42 楼& Yancy 发表于
show processlist看不全的时候可以用show full processlist
第 43 楼& snowfeng 发表于
晕，怎么是乱码？上文
第 44 楼& snowfeng 发表于
小辉，灵格王子，我也遇到你的问题了，我的dz数据库超过1G，在线人数3000以上。最近服务器的cpu一直保持在百分九十以上，dz论坛访问就非常困难了，也影响了我的uchome，当我把dz论坛关闭的时候，uchome却一直正常，cpu的使用率也下来了，说明dz论坛的表可能有些问题。请问，该如何解决？能帮帮我吗？最近一直很彷徨，哎。
第 45 楼& snowfeng 发表于
灵格王子，请联系我，我遇到与你一样的问题。我的QQ：，希望小辉保留一下，如果小辉有时间帮我诊断一下，那就太好了。在此感谢!
第 46 楼& doveying 发表于
辉哥你好，不知道你还有没有在管理这个blog，我用的是discuz X2.5的用你的数据库语句，是没有该表，而且关闭phpmyadmin后，w3wp的占用没有下降，我怀疑问题是出在discuz上，因为安装过不少插件，现在把插件全部关闭了，但w3wp的占用，依旧没有下降，重启了iis之后，它的占用很低，内存也低，一旦久了，或者上线人数多了，就会飙高，，mysqld的占用始终都在5%一下，所以我很迷惘。如果你有空，请联系下我好么？qq：
XiaoHui 回复于
16:40 : 你好。我久没有接触DZ了。X2.5的数据结构更不熟悉。不过，mysql 占用 5%，这压力并不严重啊。以前严重的都是100%高居不下。你若有心查找，可以按我笔记中的要点，先记录慢查询，看看是哪里的问题。
共有评论 49 条, 显示 46 条。
发表你的评论如果你想针对此文发表评论, 请填写下列表单:
可选 (不会被公开)
网站 / Blog:
反垃圾广告:
为了防止广告机器人自动发贴, 请计算下列表达式的值:4 + 18 =
你可以使用下列标签修饰文字:
[b] 文字 [/b]: 加粗文字
[quote] 文字 [/quote]: 引用文字
建站于 1997 ◇ 做一名最好的开发者是我不变的理想……
Copyright(C) 1997- & All rights reserved
声明：站内所有原创文字，未经许可，均可转载、复制。
转载时必须以链接形式注明作者和原始出处。&