MySQL单表日均15万数据,主要用来存储数据。有什么可靠的方案？

有3张表，每张表10个栏位。每天单表会大概插入15万条数据。考虑到时间日积月累，数据会很多。目前只考虑存储数据方案，后期可能会对数据做一些简单的查询。（网上找过的方案，分表，分区，分库）由于没有过大数据的经验，希望有过经验的大神提点下方案设计需要考虑的坑。

大家都回答到了点上，每天15w的插入，量不大。我来补充一下。

如果栏位都很简单，一天撑死几M的数据增量。怎么处理都成，分库分表有点杀鸡用牛刀了。

如果只是归档存储用，没有查询的话，不需要加什么索引，堆个一年两年的数据也不大，磁碟扛得住就成。

如果后续有查询的需求，可以考虑比如做历史表和当前活跃数据表，历史表可以按年或者月分子表，也很多简单。

其实有个很corner的case可以讨论，就是题主的这十个列里有没有特别大的text类的栏位，比如每行存了一本百万字的小说，这种情况下会比较影响性能，其他情况才是个列，都随便玩。如果是这个情况，建议把大栏位，作为文件，存到fastdfs之类的分散式文件系统里，这里存文件地址即可。

如果业务复杂，列很多，数量量再大上1-2个数量级，可以考虑用shardingsphere之类的数据中间件，做读写分离和分库分表，比如分128个子表，单表降低到现在的水平。

如果读写比很高，查询量是写入的很多倍，QPS/TPS较大，考虑对于热数据加一层缓存来保护资料库。如果还是很大，可以考虑用ElasticSearch之类的来处理了。

题主对大数据和MySQL看来有什么误解。

首先，每天15万，一年也就5000多万，十年才5亿多。从数据量来说，够上大数据的标准真是路漫漫。

其次，刚开始仅存储，以后才有简单查询。对于MySQL也没任何压力。

所以，别想那么多，用MySQL裸上，要什么分库分表啥的。有时候考虑太多就是过度设计。

如果题主所指的可靠是数据的高可靠和服务高可用，那就说来话长了

不喜欢有些回答问题的人的态度,多大的数据量是否成为压力要看对应的机器配置.给你个树梅派跑mysql你来试试分钟级别15w的日志记录入库?

楼主的问题应该是担心mysql单表能承担多大的数据量的问题,就问题来看,存储的数据类型偏日志类型,基本只存不写.那建表的时候也就不需要建任何索引,默认cluster索引即可(也就是有个主键就行).

至於单表能承担多大数据量,楼主不用担心,这个限制基本不在资料库,而在资料库mysql运行的操作系统的限制.

如果你是fat32的文件系统,那么你单表单存储文件的上限是4g,再比如ext2文件系统如果块大小为1024位元组的话，单一文件最大容量是16GB;块大小为4096位元组的话，单一文件最大容量为2T.这里的坑楼主注意去看看自己mysql运行所处的环境,因为不知道楼主的单行的数据量多大,所以楼主具体情况自己分析一下.

还有就是单表的大小也受表空间的大小的影响,这个决定了单表的上限:

比如:innodb pagesize:4KB;Maximum Tablespace Size:16TB

所以就大胆的单表来存储数据,后续如果有稍微复杂的数据查询,先建索引看查询的效果,再进一步考虑优化的空间.目前这种情况,不需要过度设计.分库分表这些东西本质上都是特定情况下的权宜之计,按照你目前的这个增量和业务需求,不需要提前设计.

ref: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html

这么点数据，要啥方案。

单表、单日15w，一年数据是5000w，三年是1.5亿，从数据量的角度来看并不算大。「主要是存储数据」可以认为没有复杂的计算，那就从容量、高可用两个角度来阐述下吧。

容量方面: 保存三年热数据

1.栏位少且简单：直接用mysql来扛也没问题，超过三年的冷数据逐渐归档到hdfs、s3之类的文件存储上或者hbase上作为冷数据提供查询；

2.栏位比较多或容量增加比较大：这里其实假定单机容量、IO性能达到瓶颈，需要进行分片存储，也就是常说的分库、分表操作。以分表为例也有几种方式:hash、range、日期，hash方式比较均匀，但是扩容不方便，只能进行翻倍扩容(像是vitess具备resharding能力，也是我感觉proxy里做的最好的，这种可以任意增减分片扩缩容量)，rang方案没有扩容的压力，

但是不能缩容并且随著时间的推移，最近访问的范围往往会成为热点，如果是IM业务我们可以按照日期进行分表。当然分库分表也有客户端、proxy代理、data mesh(趋势，很少用)几种方式，可能因为自己做中间件，我比较喜欢proxy的方式，控制力比较足、业务侵入小，方便架构、运维统一治理。这类proxy有很多vitess(部署难度比较大，但是功能很强大)、

kingshard、gaea、shardingsphere(好像也有proxy方案)、mycat等等。

3.如果读请求比较多，可以在中间件配置读写分离或加缓存等，都可以解决读多写少问题。

4.其实，这个问题提问者有潜在的容量焦虑，像是newsql这类方案目前已经比较成熟了，很推荐tidb，容量、高可用、读写场景都可以一并解决，我司(伴鱼，在线英语教育)从16年开始就All

in tidb，大小表都是，也踩了不少坑，总结来看就是时延稍微比mysql长一点，但是完全不影响业务(db这点时延对业务全流程来讲还是很小的)，但是运维起来是真心不错，目前也在实验4.0版本了。

我以前也搞过kingshard、gaea，中间件方案搞起来是真挺痛苦的，加入分散式事务、resharding功能也挺难的，所以如果有容量问题，还是比较推荐tidb的。

高可用方面:

这个就简单讲一下，一般就是mysql一主多从，然后通过MHA、orchestrator尽量保证主从切换时的数据一致性，另外MGR也有部分公司在用，但是还有有一定风险和学习成本，当前不太推荐。