记一次小数据量业务数据库瘦身

疫情这几年不太景气,公司决定对线上服务器资源进行压缩控制成本,其中之一需要对某个业务mysql数据库进行表瘦身(因为数据量不大也没到需做分库分表的程度,里面存放了N年的数据但是平常又用不到)。最大单表不到五千万数据,目前没有专业的DBA岗位都是开发跟运维操作的,在此简单记录下。

#00、准备工作

1、统计业务数据库全部表空间占用情况以及对应的业务功能模块

2、指定初步的业务表归档方案,并与关联的业务方以及财务沟通数据查询使用需求

3、安排开发根据沟通后的数据保留方案输出sql语句删除历史数据(操作前需运维进行表备份以及全库备份)

4、确定技术实施方案后,与运营、数据中台等部门沟通数据库瘦身操作节点,确保实施节点前后运营不会上线活动,以及数据部门连库取数相关功能暂停,虽然项目做了读写分离但是后台管理系统为了确保准确性及实时性还是用的主库,故需要同步平台客服以及相关商户客户系统维护相关事宜。

5、上报相关方案及当前对接情况给上级领导,这一点一定要做至少我个人是建议事前事后都汇报,千万不要自行安排做完事情后再汇报结果,领导一般不喜欢“惊喜”,需要有一个掌控感的过程!毕竟这也不是小事,出锅了可能接不住……

#01、去吧,皮卡 ~丘!

0、在操作日期前已让运维进行过全库备份及表备份工作

1、业务操作前,停止管理后台(移动端后台正常开放) ,同步通知相关部门维护开始

2、运维及开发双人在场开始执行维护sql,为了确保稳定性一张表操作完毕后再操作下一张表。维护过程中数据库主从同步延迟报警开始出现,延迟高达300s。经排查还是维护sql的问题产生了大事务,好在不是业务高峰期。因为操作耗时较长超过预期,在引起严重主从同步延迟的表操作完毕后就结束了数据库维护。然后召集小组成员分析现象原因及优化方案,制定了新的方案计划到次日同一时间执行。

3、次日根据优化后的方案把剩余表操作完毕,期间也出现了主从延迟但没之前的夸张。

4、维护完毕后mysql的数据库及表空间并没有被释放多少,这个是mysql机制问题并不是说数据delete了空间就释放了,然后我们又重新整理表碎片修复重建索引后空间明显减少。

#10、这次表瘦身的总结

1、最早制定的mysql操作方案一是我们是直接根据指定条件delete数据的,类似“ DELETE FROM 表名称 WHERE 条件”,这个语句理解起来十分简单,虽然只有一句但因为表比较大,其实是个大事务也会导致锁表。这是个风险比较大的语句,根据网友经验来说直接delete在大数据量情况下可能会把mysql的cpu负载打爆,而且越删越慢。

2、方案二是在方案一基础上增加了limit语句(需要where后面的条件有走索引 这时的limit才有意义),每次只操作10万条。因为是历史数据所以可以慢慢循环执行。

3、好在这种操作不频繁,不然真需要一个专业点的DBA或者架构师吧!还有一个就是管理后台居然忘记做公告系统,不然可以提前发维护公告,这次只是在沟通大群发了维护通知还是有不看群的商户打电话来问情况,后面可以考虑做个公告模块,然后维护的时候前端可以展示相关信息(如果后台停服了,也可以让运维配下nginx转发后台的前端url到一个提前做好的通知地址,等维护完毕后再恢复)

4、那么在mysql中批量删除大量数据有没有别的更优雅的方式呢,网上也能搜到很多答案,我也按我个人能理解的范围简单总结了下(不一定对,如果有错误之处欢迎指正)。 首选,在操作前可以考虑把原表的索引进行删除(保留1-2个必要的索引,务必先保存当前索引的DDL),这样删数据时重建索引的时间会缩短,等操作完毕后再重新添加索引。其次,使用带limit且走索引的方式来写delete语句,这种情况下要想省事建议写java或python来循环执行删除,比如有100W数据要删除每次只删除1w条,手点的话得累死,而且如果是按月份这种条件来删除的话手动效率太慢(因为每次都要修改月份条件)。最后如果可以停服或者表清空那么最简单了,可以通过先新建一个结构完全一样名字不同的表,然后通过RENAME TABLE的方式来实现瞬间切换(当然这个功能如果利用的好在一定业务场景下也可以实现不停服无损切表)

如果要清空表数据建议直接用truncate,效率远高于 delete。因为truncate不走事务、不会锁表、不会生产大量日志写入日志文件;
truncate表后立刻释放磁盘空间并重置auto_increment,而delete不会释放磁盘空间,但后面如果有insert语句则会覆盖在之前删除的数据上。

参考:

https://www.cnblogs.com/NaughtyCat/p/one-fast-way-to-delete-huge-data-in-mysql.html
https://www.cnblogs.com/miaoying/p/13748558.html

基于互联网精神,在注明出处的前提下本站文章可自由转载!

本文链接:https://ranjuan.cn/mysql-delete-bigdata/

赞赏

微信赞赏支付宝赞赏

mac-scrcpy-android-wifi
format-deleted-files-recovery
weixin-image-mode