如題

InnoDB的table，里面的字段非常簡單，如圖中的類型

才100多W的數(shù)據(jù)量，數(shù)據(jù)是慢慢積累起來的，到了最近發(fā)現(xiàn)漲到12G后，會每天成倍的增長，最高到達過50G，而數(shù)據(jù)量還是那些，longtext的字段中的存放是一組list的持久化數(shù)據(jù)最長1000個

在這個時候如果使用optimize table可以把表優(yōu)化到7,8G的樣子，但跑幾天就又會漲上來。

用最近的幾天數(shù)據(jù)來說

2.9 12G

2.10 36G

2.11 58G

我有看過information_schema.TABLES中的記錄和du -h ibd文件的大小是相符的，而文件占用空間大小也是data_length占了大頭，不是索引占的！

由于我一直在懷疑longtext的問題，所以把table給壓縮了alter table row_format=compressed;增長的確有1,2天平穩(wěn)了些，但現(xiàn)在又開始異常的增長了。

從上面3天的數(shù)據(jù)看很明顯這里面有問題！sql server有配置表空間到了一定大小可以每次增長多少，但mysql沒有聽說過，最近我也在找問題也搜了很久，都沒有頭緒，不知道大家有什么想法？

下面是幾個考慮點，我可以給出準確的答復(fù)，希望大家不要再懷疑

1.我可以保證longtext存放的是定量的，而且不會有突出的增長，是平穩(wěn)的

2.mysql的配置是單獨存在到ibd，沒有使用共享

3.文件空間占用也的確是data_length在異常的占用

4.binlog也沒有開啟

5.my.cnf中innodb_file_format=barracuda，mysql的變量也沒有錯，肯定套用了barracuda

總結(jié)

以上是生活随笔為你收集整理的mysql数据异常增长_mysql表到一定数据量后会异常的增长的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。