1 背景

电商系统一般都会有一张表记录买家的浏览器信息包含但不限于浏览器ip、浏览器cookie信息、浏览器user-agent、当前页面的url、当前页面的refer。买家在电商网站上每一次操作都会记录到该表。该表的数量量至少达到千万级级别。该表有什么用处用于给电商系统的B端做数据分析、数据概览展示、报表展示使用的。也能用于挖掘数据价值。做数据统计的查询千万级的表查询性能极低因此针对不提升数据库性能的情况下不增加服务器成本与业务方协商取得同意允许保留最近3个月的数据。那么怎么保留最近3个月的数据呢如何独立地完成这项任务

2 前言

此博客非面试题而是真实遇到的场景如果没接触过这种场景还真不知道要怎么搞。因为生产环境正在使用着这张千万级的表不能简单地认为操作navicat将数据导出然后再导入。稍有不慎就会导致生产级别的故障。

3 解决方案

核心思路先建表然后重命名表

假设这张千万级的数据表的名字是t_broswer_page_view下面也简称为pv表

1. 先创建一张与pv表结构一样的表表名随意此处用t_broswer_page_view_bak
2. 将t_browser_page_view表重命名为另一个名字此处用t_browser_page_view_20230113
3. 将t_broswer_page_view_bak重命名为t_broswer_page_view
4. 根据业务需要将最近的几天数据从t_browser_page_view_20230113迁移到t_broswer_page_view。然后将剩下需要保留的数据迁移到t_broswer_page_view。

疑问为什么要先建表然后重命名而不是先将pv表重命名为t_browser_page_view_20230113然后直接建表pv表

如果采用后者如果建表的SQL出现问题导致建表失败那么生产环境就会出现长时间该表不可用的情况会引发生产故障。而采用前者我们把表建好剩下的就是只需重命名的操作重命名的操作只需1秒即生产环境该表不可用的时间只是1秒而已。因此采用前者的解决方案。

4 注意点

1. 迁移数据的操作如果需要运维人员执行最好是提供需要执行的SQL脚本这样可以减少沟通成本和降低出错概率。
2. 数据迁移前必须和领导、业务部门达成一致的沟通结果然后再进行数据迁移迁移完成后要及时告知领导以及业务部门形成闭环。
3. 数据迁移前自己必须要有一个优化效果。比如统计迁移前有多少条数据迁移后有多少条数据删除了多少条数据即节省了多少磁盘空间提升了多少数据库性能通常可以用半分比描述。
4. 后端开发工程师需要偶尔看看迁移后的数据是否正常每隔若干分钟看看数据的产生是否正常。