Mysql，千万级大表的分区如何设计？

[black11black]

如题，最近有一个业务需求是需要存储全国各地的历史天气数据，精确到县级市（大约三千个左右）。粗略估算了一下，就算只存 20 年的历史数据，行数也要有千万级了，这种情况下该如何设计呢？

表的字段设计应该就是一列 ID （主键自增）、地名、日期（地名和日期合成唯一索引）、天气代号，这样四列。但是现在有一个问题就是，并不是所有地区的数据都能获取完全，比如北京上海这种地方可以获取到很久以前的天气，但是很多县级市只能获取到最近几年的数据，所以对于每个地方而言，需要存储的长度是不相等的。这就导致没办法直接按时间划分，比如每五年的数据分一个区，如果这么干的话会导致各分区大小差别很大。我经验比较浅薄，不知道这种时候该怎么设计了，有带佬指点一下吗

===============

当然还有一些比较取巧的办法，比如天气通常都是连续的，只存每一段天气的开头和结尾日期的话存储端的压力会小很多，但是这样会增加业务端的复杂的，除非存储端搞不定，否则目前暂时不想这么做。

[louislivi]

千万还好，上亿级就确实需要好好设计架构一下了

[594duck]

@69partner 他这要求肯定是有自己服务器的企业了。没必要用 docker 。数据量 redis cluster 5 分区，每分区 30G 足够了。而且就算是 redis 数据也是长久存储的，要什么 docker 直接 vm 跑着就好了。

对了虚拟化用 vmware 家的省心。

[sagaxu]

我是穿越回 2000 了吗？ 1000 万也算大表了吗？现在是 2020 年，10 个字段单表 1 亿行也不算大。
线上单表 2 亿，加字段加索引并不会锁表。迁移的话，10 张 1000 万的表，比 1 张 1 亿的表更麻烦。

[Coolha]

千万没必要吧...只有设计好索引，不影响使用的

[opengps]

合理的设计就没有上限，每次看到这类话题我都秀一下我的这篇文章 https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex