rq 于 2007-09-06 17:37(16 年以前) 发表:
小辉，我认为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 回复于 2007-09-07 11:34:
多谢批评指正. 复合索引这块我了解.
我后来查看了一下, 造成这个现象, 有两个原因:
1. 用户升级论坛程序之后, 没有升级数据表的结构. 新近的程序, 采用的数据表结构也不一样, 索引也不一样. 用户没有升级这块, 所以造成查询耗时. 这个原因, 是由于我在查看用户实际的数据表结构与 discuz 最新安装程序的 install SQL 时发现的.
2. discuz 本身有部分没有考虑到索引的问题. 这个我在查看最新的 discuz 论坛源码以及 install SQL 源码时, 得到的验证.
但总的来说, 以第一条原因居多. 所以我在文中对 discuz 的指责, 确实有些过于偏激. 在此愿意表示道歉.
索引的滥加确实会造成写入和更新的速度. 但我觉得这篇文章里提到的更改方式, 应该是正确的. 毕竟有一个看得见的 2kw 记录实际解决效果在这里.