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（因为数据概览的页面一般都会默认展示当天或者最近一周的数据，因此我们首先迁移的是最近7天的数据）。然后将剩下需要保留的数据迁移到t_broswer_page_view。

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

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

4 注意点

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