crazy

落伍的帖子表已经超过30G了，单表过大造成IO压力过大。
之前试过使用存档的方式，分布式存储，这个方法效果非常明显，但是最大的坏处是，存档了的部分，无法通过搜索找到，只能访问直接的url，非常影响用户体验。
后来升级服务器之后，把存档合并了回来，因为硬件升级带来的性能提升能支撑得起来。
最近，访问速度又开始明显降低，IO压力又来了，只有再想办法降低能耗了。

目前的方案：
thread表转换成InnoDB并且是使用MySQL自动的分表功能，再加后台的主题分表功能来存档旧的主题。
post表使用Discuz的分表功能分表，再加上MySQL自带的分表来降低单个文件的大小，提升读取性能。

主要问题：表太大，在Discuz后台根本分不动，只有手动导出SQL语句来分。
具体方法就是先备份post表，然后在后台做帖子分表，然后把一部分post数据插入到新建的分表中（例如tid<10000000），注意是tid不是pid，至于为何大家仔细一想就明白了。
主的post表里面tid<10000000的记录都删掉
表分开了，但是不要忘记更新thread表里面的记录，否则查询不到分出来的内容的
update pre_forum_thread set `posttableid`=0 where `tid`>9999999;
update pre_forum_thread set `posttableid`=1 where `tid`<10000000;

详细的过程就不再一一描述了。
有中大型论坛维护需要的，欢迎找我维护，落伍优惠价。

wuzhicheng

如果早期的数据小的话，可以直接在后台分表么？

crazy

wuzhicheng 发表于 2016-5-28 20:33
如果早期的数据小的话，可以直接在后台分表么？

数据小可以，但是，数据小，分了有意义么？

娃哈哈

猪头包你一天一晚得多少钱

参观者

不错，学习了

logo设计专家

暴力点 直接把一些垃圾贴删除吧

wuzhicheng

crazy 发表于 2016-5-28 20:33
数据小可以，但是，数据小，分了有意义么？

这倒也是。

域名服务

搞定了 就不错  

小闲云野鹤

mysql分表是按什么来切分？

crazy

小闲云野鹤 发表于 2016-5-28 21:20
mysql分表是按什么来切分？

HASH (pid)
RANGE (tid)