然后我登陆mys"/>

数据库的容量很诡异...

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库的容量很诡异...相关的知识,希望对你有一定的参考价值。

今天接收到金山云的报警,说有一个数据库出现了容量报警,我登上控制台一看,如图:

技术分享

然后我登陆mysql client,在命令行里查询数据库的大小却是这样的值:

技术分享


这里外里相差了近乎20个G,那么20个G的差距在哪里呢?


使用show binary logs;看看binlog,算了一下大约5G左右,还是有15G左右的出入。这个出入比较大了,然后记得曾经看过“如果存在对一个 InnoDB 表长时间不结束的查询,而且在查询过程中表有大量的数据变化,则会生成大量的 Undo 信息,导致 ibdata1文件尺寸增加。由于 MySQL 内部机制的限制,ibdata1 文件目前是不支持收缩的。


于是就要查询一下ibdata文件的大小,但是由于我是mysql client,而查询ibdata是要使用innochecksum命令在mysql server段操作的,于是就拜托金山的售后帮忙查询一番,金山查了一下,结果144M,在那消失的15G面前完全就是忽略不计。


这里额外说一句,ibdata文件不大就说明数据库的慢操作很少,运行状态还算正常。


这个时候就又麻烦金山du了一下数据大小的具体分布,如图:

技术分享

技术分享


这些值加起来是84.6G,再加上binlog日志的5个G,就差不多有90个G了。由此可见SELECT CONCAT 这个语句根本不准,实际情况要远大于这个值。




本文出自 “生活就是等待戈多” 博客,请务必保留此出处http://chenx1242.blog.51cto.com/10430133/1947643

以上是关于数据库的容量很诡异...的主要内容,如果未能解决你的问题,请参考以下文章

Oracle一个诡异的临时表空间不足的问题

Oracle一个诡异的临时表空间不足的问题

计算机改名导致数据库链接的诡异问题

33岁高龄程序员离开大厂进工厂,场面堪比春运,诡异吗?很诡异

一次因网络引起的诡异GC问题,DBA该怎么做?

Redis 一个很诡异的问题(部署)