求论坛分区方案
0
悬赏园豆：20
[已解决问题]
解决于 2008-05-27 08:58
<SPAN>
<P align=left>论坛最常用的功能有两个，一是版面首页显示版面的帖子列表；二是显示帖子和帖子回复<BR>现在我建了帖子表<BR>----------------------------<BR>USE [DB_Forum]<BR>GO<BR>CREATE TABLE [dbo].[Forum_Post_tab](<BR> [ID] [bigint] NOT NULL,<BR> [BoardID] [int] NOT NULL,<BR> [Title] [nvarchar](50) COLLATE Chinese_PRC_CI_AS NOT NULL,<BR> [Content] [nvarchar](max) COLLATE Chinese_PRC_CI_AS NOT NULL,<BR> [ReplyCount] [int] NOT NULL,<BR> [PageView] [int] NOT NULL,<BR> [StatusFlags] [int] NOT NULL,<BR> [CreateUserID] [bigint] NOT NULL,<BR> [CreateUserName] [varchar](40) COLLATE Chinese_PRC_CI_AS NOT NULL,<BR> [CreateTime] [datetime] NOT NULL,<BR> [CreateIP] [varchar](20) COLLATE Chinese_PRC_CI_AS NOT NULL,<BR> [UpdateIP] [varchar](20) COLLATE Chinese_PRC_CI_AS NULL,<BR> [LatestReplyTime] [datetime] NOT NULL,<BR> [LatestReplyUserID] [bigint] NULL,<BR> [LatestReplyUserName] [nvarchar](18) COLLATE Chinese_PRC_CI_AS NULL,<BR> [ResourceCode] [nvarchar](50) COLLATE Chinese_PRC_CI_AS NULL,<BR> [PollIDs] [varchar](200) COLLATE Chinese_PRC_CI_AS NULL) <BR>GO<BR>--------------------<BR>想对该表进行表分区，我计划的分区方案是根据版面来进行分区，例如版面id为1-100的在一个分区上，101-200的在一个分区上；这样分区就需要把BoardID放在聚集索引中，于是我在两列ID和BoardID上建了聚集索引。</P>
<P align=left>这样分区的原因有二，一可以提高帖子列表页的帖子列表的查询速度；二是在显示帖子详细页时我总是会传BoardID和PostID这样在查询的条件中我可以先写BoardID = @boardID AND ID = @postID希望这样可以提高帖子详细页数据查询的效率</P>
<P align=left> </P>
<P align=left>请各位指点，我这样做是否合适？有什么问题，有没有合适的方案？</P>
<P align=left> </P>
<P align=left>先谢过大家。</P></SPAN>
最佳答案
0
这个问题需要从逻辑和物理两方面来看。
逻辑方面：
1． 同上面各位兄弟说的，数据量不大就别分区了（这对物理方面的影响是很大的）。
2． 你的版面有那么多吗？如果要在某一个版面中列出所有帖子标题的话，为什么不直接按版面分区？或者可以将量大的单独放一个分区，量少的放在一起（方法很简单，从版面ID入手，也就是说好好对你的版面进行ID设计）。如果仅仅是为了分区而分区，那还不如不要分区。
3． 你的论坛不用全站查询？如果要列出全站的帖子列表呢？这样的情况多不多？聚集索引会随了表分区的哦，这个对性能不是没有影响的哦。如果你用的是SQLServer2005的话，这样的查询实现起来虽然不会像SQLServer2000那么费事，但是除了执行计划好了那么一些些之外，别的几乎没区别的。
物理方面：（总的一句话，数据库就是一堆放在硬盘上的东西，性能在很大程度上其实就是读写速度）
1. 你的这些分区有没有硬件支持（就是说硬盘，还有就是CPU了，不过CPU的作用稍微小点，要看你的查询用不用得上了，此外，还有一些其他的硬件支持，这里不多说了）？没有的话，实际上也起不了多么多么显著的作用，至少也要多弄几个文件组吧？（但这又影响了全站帖子列表的性能。）
2. 你的分区列为版面ID，且聚合也在这里，这个倒是不错，可以避免不必要的空间浪费，这也无形中为性能提升带来了机会。
这个问题说起来真是太费口舌了，这样说吧，建议你按各版面的帖子量进行分区，好好设计一下版面ID即可。如果是SQLServer2005，要加减分区也是一件非常简单的事情，而且不会浪费什么资源（几乎仅仅就是配置，不会涉及到数据迁移的，所以这个操作是很快的）。
另外，再多说几句：
1. 你的聚集索引一定要弄好顺序，不然就郁闷了。（兴许这是废话）
2. “一可以提高帖子列表页的帖子列表的查询速度”，的确，不过仅仅是同版面内的，跨版面的就不好说了，搞不好会比没分区时更慢（情况太多，兄弟就自己慢慢测试吧）。
3. “二是在显示帖子详细页时我总是会传BoardID和PostID这样在查询的条件中我可以先写BoardID = @boardID AND ID = @postID希望这样可以提高帖子详细页数据查询的效率”。首先，不要低估了查询优化器的本事。第二，如果只是要找某一个帖子的内容，这里高出来的性能几乎可以忽略不计。第三，你这个条件就已经定死了某条post了，其他的查询条件将直接54。
说了这么多，不知道lz是否看糊涂了，没办法，我对数据库也只是一知半解，权当是抛砖引玉了……囧rz
反正我对数据库优化的理解就是：要全盘考虑，否则不要贸然乱搞，否则可能会犯“捡了芝麻丢了西瓜”的原则性错误^_^
其他回答(4)
0
好象有点过度优化~~~你贴子量有多少了啊~~用得着吗~~
0
1 您说到：" 这样分区就需要把BoardID放在聚集索引中，于是我在两列ID和BoardID上建了聚集索引"
-- 一个表上 可以建立两个聚集索引么？
2 该表是帖子表，大概在一般的论坛中（例如Discuz!NT)相当于dnt_topics吧, 不知道存储回复的表什么结构呢？
3 您所说的分区应该是对表进行横向分区吧，这样需要一个表来记录分表的具体范围情况 Forum_PostTableList_tab
例如
ID PostTableName BoardMinID BoardMaxID
1 Forum_Post1_tab 1 100
2 Forum_Post2_tab 101 200
一般情况下一个论坛的版块不会太多，有200已经算是极品了，这样在您的帖子表中将会有很多BoardID重复的记录，貌似这样的记录还算适合建立聚集索引吧
但是 我想 您需要在从帖子列表页（主题列表页）转向帖子详细页时 带一个BoardID过来才行。
您些 BoardID = @boardID AND ID = @postID 其中的 【ID】 应该是 回复表中的ID吧。 而@PostID是 帖子表中的ID吧。。。
小弟悟性实在不好，可能理解错误了 ……
0
我也感觉有点过度优化了 一个论坛实际活跃的BoardID能有几个呢 不多吧 这比例建聚集似乎不很合适，而且这个表按说应该是比较常进行插入的
0
看你数据什么量级的，同楼上，帖子量不大根本不需要这么设计，回复表分区的意义更大