订单表,现在数据量很大,每天增量 10w,表用到的场景是插入,搜索三天内的数据,更新。
也就是说三天前的数据是用不到的。
如果按月分割,那么上个月最后三天的数据就操作不了,不然代码里要加很多逻辑处理。
这种情况如何分表呢?
订单表,现在数据量很大,每天增量 10w,表用到的场景是插入,搜索三天内的数据,更新。
也就是说三天前的数据是用不到的。
如果按月分割,那么上个月最后三天的数据就操作不了,不然代码里要加很多逻辑处理。
这种情况如何分表呢?
|
qiayueOct 23, 2020
1
有一张实时表,所有的实时操作都在这张表操作。
有另一个定时任务,把超过 3 天的订单移动到月表。 |
|
2
@qiayue 我也考虑过这样,innodb delete 会锁表吗
|
|
IMCA1024Oct 23, 2020
3
|
|
4
@IMCA1024 这会导致插入订单
|
|
RisclyOct 23, 2020 via iPhone
5
1 、实时表 /Redis 缓存,优点:开发快,缺点:增加数据库压力
2 、上个 elasticsearch,优点:搜得快,后续可以搞搜索也能用上,缺点:开发成本高,如果有批量修改的话还是麻烦 |
|
6
@Riscly 不想再引入 redis 进入订单
|
|
longchen888Oct 23, 2020
7
有一张实时表,所有的实时操作都在这张表操作。
有另一个定时任务,把超过 3 天的订单移动到月表。 -------- 迁移数据的时候,分页(比如一页 500 条)迁移数据,迁移完后,根据 ID 批量删除,应该就不会锁表了,想快的话,就多线程迁移;缺点是慢,优点是稳 |
|
dorothyRENOct 23, 2020
8
加一个三天的表不就行了
|
|
rrfengOct 23, 2020
9
那你就按天建表呗,取个约数不就不存在跨表问题了。
并且 drop 的时候也不会锁你的业务。 |
|
MaxFangOct 23, 2020
10
主表用于新数据插入,和最近 3 个月数据的查询。
历史表可以按月等分表,每天脚本处理,从主表中筛选出超过 3 个月的订单数据,插入历史归中。 如果每天都操作,每天的处理量也就一天的数据,按每天 10W 的数据来看,插入历史表和从主表删除,即使根据单个 id 来处理也完全够用。如果要加快速度,简单的方法,分页批量操作,或者按 ID 取模多脚本操作。 |
|
WaldenHorizonOct 23, 2020
11
不用分表,计划任务凌晨随便搞
|
|
wangyanruiOct 23, 2020 via Android
12
插个楼
不要为了分表而分表,一天约十万的插入量完全可以扛得住 产品的需求时时在变化 不要提前优化 不要提前优化 不要提前优化 建议:先抗住,量大了迁移到 TiDB 或者加个 ES |
|
kanepan19Oct 24, 2020
13
我们当前一天 200W 的量单表也没问题.
如果一定要分表, 可以考虑按时间分表 ,按月或者按日分表 |
|
fengpan567Oct 24, 2020
14
上 sharding jdbc,按日期分表
|