请教超大记录集表的设计

Submitted by neka on 周三, 2007/10/31 - 14:50

记录集到了千万级的数量级，并且有频繁的读写操作，目前采用MRG_MyISAM表，优点是查询很快，缺点是写的入口只有一个，并且每次写的时候mysql内部把整个表都锁定了，更新操作很慢，并且在高并发的情况下，经常出错，请教一下有没有其它的解决方案。

Taxonomy upgrade extras:

yejr

周三, 2007/10/31 - 20:29

既然是这么大数据量的表，还要那么频繁的写入，从设计角度来讲已经很不合理了。
建议拆分成母表和子表，字表可以采用内存表的方式，那么就快多了；由此带来的不变，就由程序端来处理吧。

MySQL方案、培训、支持
MySQL 用户组

neka

周三, 2007/10/31 - 20:48

我不太明白母表和子表意思，能够详细说明一下吗？

yejr

周三, 2007/10/31 - 20:55

大表和小表的意思啊，或者说频繁更新的表和基本上无需更新的表。

MySQL方案、培训、支持
MySQL 用户组

caramon

周四, 2007/11/15 - 00:22

从另外一个角度考虑，如果预计到了这种数据量，可以考虑分表或者分库的方法，当然，这要根据实际业务需求做调整的。
例如你要处理全国的某种类型的数据，完全可以一个城市一个库，每个城市里根据数据的特性还可以再拆分表，由前端应用程序来判断使用哪个库的哪个表，后面数据库服务器分成多个。。。拆表最简单的原则。。。当然了，不是书里写的呀。。。可以依据数据的特性，数据的用处，数据的增长比例进行拆的操作。优先去拆数据增长量大的表。根据数据增长的特性，比如是一个城市的电话单子，个人觉得就可以按照天来进行表的拆分。当然，如果考虑到个人还要进行某个月的单子的查询，也可以按照人/年或者人/天的方式来拆表，例如，考虑用户一个月不可能打一1000个电话就可以把用户编号1-800的信息放在一张人/月表里，把用户编号801-1600的信息第二张人/月表里，同时在用户个人信息表里设置TRIGGER，当用户的标号达到某一个点的时候会调用建立新的人/月表的代码。这样前端程序当有用户登陆的时候就可以知道去哪张表寻找数据了，当然这里说的大部分例子不大可能直接拿来用，必须根据实际情况分析后得出相关结论，嘎嘎，一点个人的看法而已，别见笑