Tech Neo技巧沙龙 | 11月25号，九州云/ZStack与您一路商量云时代收集界线治理实践

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

起首这位同伙在昨世界午反馈说他有一个表大年夜小是近600G,如今须要清理数据，只保存近几个月的数据。按照这个量级，我发明这个问题应当不是很好解决，得异常谨慎才对。如不雅是通用的思路和办法，我建议是应用冷热数据分别的方法。大年夜体有下面的几类弄法：

exchange partition，这是亮点的特点，可以把分区数据和表数据交换，效力还不错。

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，这个存储比例也实袈溱太高了，或者说碎片也实袈溱太多了吧。

同伙听了下认为也有事理，大年夜安然的角度来说，只是须要留意一些技能罢了，然则没过多久，他给我反馈，说表里的数据除过碎片，大年夜概也有100多G，可能还有更多。这个问题和我之前的分析照样有一些冲突的。至少差别没有这么大年夜。200万的数据量，根本就在1G以内。然则这里倒是100多个G,远远超出我的预期。

按照这个思路来想，本身还有些成就感，发明这么大年夜的一个问题关键，如不雅数据没有特其孑遗储，200万的数据其实也不算大年夜，清理起来照样很轻易的。

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 | 
 
+----------+---------+----------+ 	
			
 1/2    1 2 下一页 尾页
	
			

　　推荐阅读
　　Facebook开源相似性搜索类库Faiss，超越已知最快算法8.5倍
            Tech Neo技巧沙龙 | 11月25号，九州云/ZStack与您一路商量云时代收集界线治理实践
            计算GPU 实现方面也做了很大年夜的投入，在原生多 GPU 的支撑下能产出惊人的单机机能。GPU 实现已经可以作>>>详细阅读


本文标题：MySQL数据清理的需求分析和改进
地址：http://www.17bianji.com/lsqh/38867.html
 1/2    1