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也有部分公司在用，但是還有有一定風險和學習成本，當前不太推薦。