杨建荣的学习笔记

每天坚持一点点,个人微信公众号: jianrong-notes, 个人邮箱:jeanrock@126.com

  • 博客访问: 12801177
  • 博文数量: 1365
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1300多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1365)

文章存档

2017年(299)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: MySQL

昨天帮一个朋友看了MySQL数据清理的问题,感觉比较有意思,具体的实施这位朋友还在做,已经差不多了,我就发出来大家一起参考借鉴下。

为了保证信息的敏感,里面的问题描述可能和真实情况不符,但是问题的处理方式是真实的。

首先这位朋友在昨天下午反馈说他有一个表大小是近600G,现在需要清理数据,只保留近几个月的数据。按照这个量级,我发现这个问题应该不是很好解决,得非常谨慎才对。如果是通用的思路和方法,我建议是使用冷热数据分离的方式。大体有下面的几类玩法:

  1. exchange partition,这是亮点的特性,可以把分区数据和表数据交换,效率还不错。

  2. rename table,这是MySQL归档数据的一大利器,在其他商业数据库里很难实现。

但是为了保险起见,我说还是得看看表结构再说。结果看到表结构,我发现这个问题和我预想的完全不一样。

这个表的ibd文件大概是600G,不是分区表,InnoDB存储引擎。字段看起来也不多。需要根据时间字段update_time抽取时间字段来删除数据。

我看了下这个表结构,字段不多,除了索引的设计上有些冗余外,直接看不到其他的问题,但是根据数据的存储情况来看,我发现这个问题有些奇怪。不知道大家发现问题没有。

这个表的主键是基于字段id,而且是主键自增,这样来看,如果要存储600G的数据,表里的数据量至少得是亿级别。但是大家再仔细看看自增列的值,会发现只有150万左右。这个差别也实在太大了。

为了进一步验证,我让朋友查询一下这个表的数据量,早上的时候他发给了我最新的数据,一看更加验证了我的猜想。

mysql> select max(Id) from test_data;

+---------+

| max(Id) |

+---------+

| 1603474 |

+---------+

1 row in set (0.00 sec)

现在的问题很明确,表里的数据不到200万,但是占用的空间近600G,这个存储比例也实在太高了,或者说碎片也实在太多了吧。

按照这个思路来想,自己还有些成就感,发现这么大的一个问题症结,如果数据没有特别的存储,200万的数据其实也不算大,清理起来还是很容易的。

朋友听了下觉得也有道理,从安全的角度来说,只是需要注意一些技巧而已,但是没过多久,他给我反馈,说表里的数据除过碎片,大概也有100多G,可能还有更多。这个问题和我之前的分析还是有一些冲突的。至少差别没有这么大。200万的数据量,基本就在1G以内。但是这里却是100多个G,远远超出我的预期。

mysql> select round(sum(data_length+index_length)/1024/1024) as total_mb,

-> round(sum(data_length)/1024/1024) as data_mb,

-> round(sum(index_length)/1024/1024) as index_mb

-> from information_schema.tables where table_name='hl_base_data';

+----------+---------+----------+

| total_mb | data_mb | index_mb |

+----------+---------+----------+

| 139202 | 139156 | 47 |

+----------+---------+----------+

1 row in set (0.00 sec)

这个问题接下来该怎么解释呢。我给这位朋友说,作为DBA,不光要对物理的操作要熟练,还要对数据需要保持敏感。

怎么理解呢,update_time没有索引,id是主键,我们完全可以估算数据的变化情况。

怎么估算呢,如果大家观察仔细,会发现两次提供的信息相差近半天,自增利的值相差是大概4000左右。一天的数据变化基本是1万。

现在距离10月1日已经有24天了,就可以直接估算出数据大概是在1363474附近。

mysql> select current_date-'20171001';

+-------------------------+

| current_date-'20171001' |

+-------------------------+

| 24 |

+-------------------------+

1 row in set (0.00 sec)

按照这个思路,我提供了语句给朋友,他一检查,和我初步的估算值差不了太多。

mysql> select id , create_time ,update_time from test_data where id=1363474;

+---------+---------------------+---------------------+

| id | create_time | update_time |

+---------+---------------------+---------------------+

| 1363474 | 2017-09-29 10:37:29 | 2017-09-29 10:37:29 |

+---------+---------------------+---------------------+

1 row in set (0.07 sec)

简单调整一下,就可以完全按照id来过滤数据来删除数据了,这个过程还是建议做到批量的删除,小步快进 。

前提还是做好备份,然后慢慢自动化完成。

阅读(36) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册