http://bbs.dedecms.com/119303
http://bbs.dedecms.com/198102
http://bbs.dedecms.com/273877
http://bbs.dedecms.com/272828
http://bbs.dedecms.com/338159
http://bbs.dedecms.com/229591
http://bbs.dedecms.com/226421
http://bbs.dedecms.com/575833
http://blog.rekfan.com/articles/105
http://blog.rekfan.com/articles/106
dedecms分表教程 发表于: 2012-07-05
很多用dede织梦做网站的朋友都会遇到数据过大的情况，这样就造成生成html速度缓慢打开栏目列表变慢等等问题，笔者根据织梦论坛部分帖子总结出默认文章模型转移数据到其他新建模型的简单教程，现在分享出来，高手可以忽略.
强力建议你在进行以下操作时先备份数据库!!!丢失或者任何错误本人概不负责。使用以下方法本人成功转移.
首页建立新模型–系统模型-新建字段-内容(body)html文本 固化字段。
现在设定下演示的相关说明，原模型是文章模型，channel=1，附加表为dede_addonarticle;新建模型x ，channel=19，附加表为dede_addon19;原栏目typeid=300 新建以x为内容模型的栏目typeid=400
接下来开始行动，在phpmyadmin或者织梦自带的sql命令行工具 运行以下命令，特别说明：因为新建模型和原普通文章模型主键一样的话会无法插入数据，提示错误：#1062 – duplicate entry ‘343’ for key ‘primary’ ，所以要在phpmyadmin里修改下新建模型附加表dede_addon19的主键aid数据类型为bigint，成都五官科医院具体方法可以百度。
我们继续，输入：
insert into dede_addon19 select * from dede_addonarticle where typeid=300;
上面这句sql的意思是 挑选出dede_addonarticle(也就是普通文章)表里栏目为300的内容插入到新建的 dede_addon19(也就是x模型)
再次运行，输入：
update dede_archives set channel =replace(channel ,’1′,’19’) where typeid=300;
意思是 把dede_archives主表里栏目为300的数据的channel 由1改成19;
再次运行，输入：
update dede_archives set typeid =replace(typeid ,’300′,’400′) where channel=19
同理把channel为19 的数据栏目由300改为400;
ok了、文章路径什么都设置好，更新下栏目缓存，生成栏目列表及内容，ok了!
这个方法适用于大量dede_addonarticle数据表的分割，http://www.scynb.com比如你这个数据表已经500m以上那么分出来势在必行。
不够完美的地方是：dede_archives主表没有分开。希望高手可以补充。
不是，一个模型可以对多个栏目，或都一样栏目都是可以的，一个模型就相当一个数据表，当这个表达到一定数据量量就重建立一个和他一样的模型，再把栏目相关的栏目指向
分表，然后如何分呢？google半天只在自定义模型处看到一点希望，接下来就按部就班的开始操作，具体操作步骤，我就不废话了，可以看下这篇文章，有图片讲的比较细致：http://cms.zz5u.net/dedecms/2009/0919/3504
但是这里有几点要注意，
第一， 要自定义模型，不要用后台那个复制现有模型，特别是用的最多的文章模型，如果你复制那个，你会发现你的负载没能提高多少，因为文章模型有三个表控制dede_addonarticle，dede_archives，dede_arctiny。这时候的分表只是解决了dede_addonarticle的问题，还有dede_archives，dede_arctiny卡着你的脖子，特别是dede_archives内容也相当多，用不了多久因为它也造成你的程序爬不动。自定义模型就不存在这个问题了，只有dede_自定义，和dede_arctiny索引表，这时候受到的制约少了，自然效率提高。
第二， 当你做完以上部分，又有一个问题，摆在你面前，就是生成静态页，还是不动。我的解决办法是用伪静态去解决，这方面比较简单了，各位可以google到，就不废话了
通过以上操作，我的环球商务通www.114b2b.com现在有将近二百万数据，一点不显慢，如果用原系统，这是不可想象的，现在应该说很好的解决了这个问题