如果Discuz可以每个版块一个数据表
性能会提高一大截 老大，人家那些大型站点，以什么方式分表好？是不是不同类型有不同方案？ 也提高不了多少吧，大部分帖子都集中在1-2个板块，有时候一个板块的帖子会占到80%以上，分表了也不见得快多少。感觉你太喜欢折腾技术了，即是好是也是坏事，好事是能提高技术水平，坏事是对自己的要求太完美，写出来的东西会很少，因为你会觉得不完美，所以说这方面来讲他是个坏事。以前我也有这个习惯，不过后来改掉了，写东西不看代码多牛逼，功能达到就ok了。 像你说的那个100g，100m的mysql备份什么的，本身mysql主从就已经实现了的。你的那个方案反而有点闭门造车的味道，从机记录下binlog，要真个备份的时候停止从机的mysqld服务，然后删除binlog打包mysql的data就可以备份了。备份好了启动mysql服务，其余时候只需要备份binlog，这样还能从打包的时间起恢复到任意的时间点。比如说你每周1打包一次，周3你不行心在主服务器执行了drop table，你想恢复就用周1备份的数据恢复，然后用binlog导到这个语句前的时间点就能恢复了。 你打算的是 把thread表 单独分开，还是把post表分开？！
只不过一个fid字段的问题而且已经有了索引了，独立分出来 能有多大起色呢
数据量大了 依然会变慢 学习学习，数据库不太懂，呵呵 。 我也觉得功能达到就ok了，不用钻牛角尖 本帖最后由 服务器之家 于 2014-12-30 10:52 编辑
匿名者 发表于 2014-12-30 08:24 static/image/common/back.gif
像你说的那个100g，100m的mysql备份什么的，本身mysql主从就已经实现了的。你的那个方案反而有点闭门造车的 ...
你说的这些我都考虑过，第一，**备份肯定是要不同机房的，跨机房做主从，可靠性不好说，我自己是不打算尝试了。第二，从公开过的文章和帖子里我只看到过FB用binlog做备份，我自己觉得，我假设的这个数据量（几十G到几百G），用binlog做备份，从复杂性考虑，没必要，这东西对精准的要求非常高，如果用这个，要考虑的东西就更多了。
另外你说的闭门造车的问题，从某些角度我认同这个说法，因为网络上涉及到这个级别的备份方案，几乎没有人提，也就是说，是个断档区，没有哪个大型网站的运维出来分享这个级别的备份方案，至少我没有看到过，如果你有这方面的资料，不妨分享下。 飞鸟网络 发表于 2014-12-30 09:40 static/image/common/back.gif
你打算的是 把thread表 单独分开，还是把post表分开？！
只不过一个fid字段的问题而且已经有了索引了， ...
每个版块对应单独的一个thread和N个post，thread中记录post的分表id。
索引是必要的，但并不是万能的。 你说的dz早就想过了。不是最优哦
页:
[1]
2