求助各位程序员大人!关于mysql分表的问题?

2012-05-10 15:36:56 +08:00
 eric_zyh
数据库有1个800w的表和几个100w的表。而且表数据增长挺快,导致mysql经常出现locked,apache请求堵塞。于是想对一下大表进行分表操作。

1.分表的子表大概存放多少条记录合适?

2.如程序中对同一个表的查询有多个查询字段应该如何处理?如:对于同一个表,有个sql需要按add_time全表排序,另外有个sql需要按照userid字段排序。

3.系统的关键表是不是不能分表,比如用户表有100w数据,几乎每个sql都有可能与该表关联。如果这种关键表表数据量过大应该如何处理?

4.对于部分增长速度很快的表(如没增加一个用户就要多出100-1000条数据)除了分表,有没有其他的方式优化?
4703 次点击
所在节点    问与答
11 条回复
EchoFUN
2012-05-10 15:49:17 +08:00
关注。
Johnny
2012-05-10 15:57:10 +08:00
对于800w的记录真心不多,你打开show-show-sql看下是哪些语句占用太长时间,优化SQL是王道
Johnny
2012-05-10 15:58:34 +08:00
@Johnny 是slow-sql
eric_zyh
2012-05-10 16:05:21 +08:00
@Johnny 谢谢~

我看了查询较慢sql确实是由于2个大表关联造成,但是这个关联操作又不能省略,而且字段都有索引。这样的话通过分表将大表切小一点能解决么?
holystrike
2012-05-10 16:08:04 +08:00
表用innodb引擎,锁行不锁表

对于分表,比较简单常用的策略,就是定量和取模分存

在这个数据量上,要尽量少用join

取模的方式就是对id进行取模运算来看数据是放在哪个表的,订单一类的数据可以考虑用这种
eric_zyh
2012-05-10 16:16:09 +08:00
@holystrike 一般多大数据量的表需要分表呢?分表之后一个表记录放多少行记录合适呢?MYSQL有没有一个参考值?
AlloVince
2012-05-10 16:20:15 +08:00
分表之前考虑一下分区的可能,很少有什么查询需要扫描全表的。10W数据一个区,把总查询拆成若干子查询,代价比分表小很多。
linlinqi
2012-05-10 17:10:33 +08:00
大表关联的话,分表也没什么用。趁早拆开
timchou
2012-05-10 17:14:10 +08:00
百万级别的数据,还不到需要考虑分库分表的时候吧。

建议试用innodb存储引擎,buffer pool设置大点,mysql版本可以使用percona 5.5。相信程序换了之后,性能会有很大的改善。

然后slow-log配合观察慢SQL。

最后,如果要考虑分库分表,那就相对比较麻烦了,主要是路由的问题
1)在程序中对主键进行取模,然后人为的定制对应表,这个办法简单,不需要引入中间层,但是扩展性很差。
2)引入比如中间层,淘宝刚刚开源的TDDL就是解决这个问题的。
kafka0102
2012-05-10 17:21:19 +08:00
@eric_zyh 对于表设计,我的经验是
1、不要用join,数据多了一定会有性能问题,表间数据的一致性使用程序保证
2、单表数据如果多于1000万,就可以考虑分表。分表策略通常就是取模,但要提前做好数据量预估,否则再次分表就要重做数据了。如果数据特点简单(比如只是按主健查询),按自增id分表比较合适。
3、如果数据规模并不大但性能还是存在问题,可以有针对性的优化,比如根据慢查询分析问题所在,看是否有其他解决办法。
4、如果是通常的访问模式(比如读多写少),可以考虑主从架构。
5、如果写并发很多,并且写条件不是针对主键的(造成innodb不能按行锁而是锁区间),可以想办法优化,比如异步写,或者分库(分库要谨慎,通常是业务独立的才分库)。
eric_zyh
2012-05-10 19:14:54 +08:00
@Johnny @holystrike @AlloVince @linlinqi @timchou @kafka0102 感谢各位,我把大表join拆开了。对大表做了分区,看看能不能好点。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/35366

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX