Ⅰ、背景
MySQL日常运维中，常会遇见大表，一方面大表会导致增删改查性能下降，另一方面会导致备份恢复成本高，包括时间成本和空间成本。如果出故障需要恢复数据，那可真磨人啊。我们有必要重视大表的梳理，以免给自己带来不必要的麻烦。
Ⅱ、表为什么这么大
从源头上看，公司业务高速发展，数据量增长快，业务迭代过程中，开发人员没有做好规划，不管什么数据，日志流水全往MySQL里怼。另一方面，针对这种情况，DBA没有及时做好相应的应对策略。短期内，皆大欢喜，你爽我也爽，时间长了，出问题了，就要互相甩锅了。
Ⅲ、开发该怎么做
类似日志流水等非核心业务数据，尽量不要放到MySQL，现在市面上可选择的中间件有很多，MySQL擅长的是高并发的oltp场景，拿来装日志流水岂不是太那啥了。如果真的非要用MySQL，强烈建议将表设计成分区表，比如按时间分区，这种数据一般都是保留一段时间即可，到时候可以直接drop过期的分区。
Ⅳ、DBA怎么做
对于已经存在的大表，需要DBA和业务沟通好，根据业务需求实施对应的方案。
4.1 表中数据可以直接抛弃
针对这种情况，我们一般和业务沟通好时间节点，将老表rename掉放在一边冷一冷。建一个新表供业务使用，最好就是改造成分区表，方便后续清理。rename过的表冷一段时间，咱们再用硬链接的方式将表处理掉来释放服务器物理存储。
4.2 表中需要保留少量数据
这种情况可以直接用pt-archive把不要的数据清掉，然后再整理表空间。也可以先走4.1流程，走完后，再用insert...select...的方式将需要保留的少量数据挪到新表中。当然，如果需要温柔一点，也可以用pt-archive来挪数据。
4.3 表中数据需要归档
如果数据需要归档，那我们就引入pt-archive，和业务定好归档条件，定期把数据归档到指定的服务器上，归档表可以用压缩表来节省存储。归档好之后还需要选择合适的时间整理原表的表空间，这样才能收缩ibd文件。
常见的方案就是这些。总之，我们的方案是灵活的，提前和业务沟通好需求即可，方法总比问题多。
