1、背景
数据库占用服务器内存越来越高,除了bin-log文件之外,还发现了一些带有text或者longtext数据类型字段的表,这种表也会占用很高的服务器磁盘空间
数据库版本:
表引擎: InnoDB
数据量:清理之前1500万,清理之后600万
2、清理
建议在系统运行中,时刻关注类似表空间是否增大,如发现异常,需要及时处理。
1、查询数据库空洞的SQL
SELECT table_schema,TABLE_NAME , concat(data_free/1024/1024,"M") FROM `information_schema`.tables WHERE data_free >8*1024*1024 AND ENGINE ='innodb' ORDER BY data_free DESC;
table_schema:库名
TABLE_NAME:表名
concat:空洞空间大小
2、清理方法
OPTIMIZE TABLE your_table_name; 这种方法不支持InnoDB引擎的表
ALTER TABLE your_table_name ENGINE=InnoDB; InnoDB引擎的表建议使用这种方法
3、注意事项
1、锁表问题
因为作者这边的表是InnoDB引擎,所以这里只验证了ALTER TABLE这种方式,在执行了SQL之后,任然有数据进入操作的表,说明不会造成锁表。
2、服务器磁盘空间是否充足
ALTER TABLE 会创建一个新的临时表,并将原表中的数据复制到新表中,然后删除原表,将新表重命名为原表的名字,在复制到新表过程中,原表未被删除的数据会占用磁盘空间,作者这边的表是有500多个G,所以在执行这个SQL之前,要确保服务器还有额外的500个G的磁盘空间
3、系统业务
执行过程中,会占用数据库服务器的资源,交换空间基本上是拉满了,内存空间占用也比较高,如果此时还有其他业务在频繁访问数据库的话,可能造成很严重的后果,所以建议选择业务低峰时期来执行
4、结语
内心非常忐忑,整个执行过程花了2小时,原本被清理的表占用了580个G左右,清理了900万左右的数据之后,执行了ALTER TABLE之后,新的表还有300多个G,也就是说在处理过程中,看着磁盘空间一点一点的减少(总共需要占用900多个G),心头慌得一批,担心服务器啥时候崩掉了。