本人菜鸟，没接触过实际生产环境
看了一下其他的开源项目，都是把帖子放在一张表里，回复放在一张表里。需要展示帖子回复的时候就去回复表里找。
感觉如果回复表很大，那查询时间不是很长么？
而且为了某一个帖子的回复，去把所有的回复找一遍，不太符合直觉......
或者说通过索引就能解决查询时长的问题？
或者说根本不是用的关系型数据库？
想问问实际情况是怎么设计处理的
——————————————10月9日补充问题————————————————
关于1楼所说的“一张大表”和我提出的“分表”的结构我都手动实现过。
我还有其他的想法：
比如把一个主题的回复全部结构化然后base64，放到“主题表”的一个字段中
再比如把一个帖子的全部回复结构化放到一个文件中，把文件放到服务器一个目录下，而“主题表”给一个文件的连接，需要的时候读取，修改
主要的问题在于“大数据量”，“高并发”，的情况，我本人没办法复现，所以想问问，实际大型项目中，到底是怎么设计的？(缓存什么的负载什么的cdn什么的先不考虑)
實際上連帖子內容也可以放在回復裏，帖子表只是主題表。
這麼說吧：主題是頁面，帖子是頁面下的文章，回復也是帖子的一種（跟帖）。
所以當請求一個頁面的時候，首先去主題表找到主題 ID（或者主題 ID 直接在 URL 裏提供，這時可跳過此步驟），然後去帖子表篩選出所有當前主題 ID 下的帖子，呈現，完事。
直覺上帖子表是一大堆鬆散的數據，然後用的時候到裏面大海撈針。可如果這樣還要數據庫幹嘛，直接把主題下的內容存到以 ID 命名的文件裏都比那樣好。
表面上帖子表是一個平坦的列表，只能遍歷，實際上表也可以實現像文件系統那樣的層次結構，而且靈活地多！雖然是一張表，但是卻有層次，找的時候順着既定的路線，效率很高。
实际上生产环境中基本也都是将两个表分开的，对于mysql来说只要表设计的合理，索引优化好，数据大基本不是问题。 也可以不用关系型数据库，貌似像twitter和weibo，用的是redis来处理的。自己动手实战理解了来的最真实,动手设计写一个简单的留言板小程序就知道如何处理了。
像本论坛的 表设计就很好哈~！
评论都在一个表里面... .. 只是一级评论里面统计了二级评论的总数.（然后显示出来 有多少评论，如果你想看，就点击一下，然后获取了二级评论)
还是不错.
我也准备按照这一来写~！