这是学习笔记的第 2078 篇文章
今天完善了一小部分的周期表的内容，所谓周期表就是我们业务中经常看到的日表，比如表名为test_data,则日表的表名为test_data_20190822,test_data_20190823这样的形式。我们是建议尽可能不要使用分区表，而采用这种日表的形式，从应用层也容易扩展，在数据统计的维度上行会有一些额外的成本。
为什么要提MySQL回收站，主要是基于现在维护的一些数据表的实际情况，最近做了下数据治理的初始工作，在完善了一小部分生命周期管理的工作之后，我惊人的发现我们的几百套数据库环境中每天会有近百表会自动创建，而随着也会有一些表会被删除，而通过明确的需求反应到我们这里的只是个位数，按照这种情况，着实让人倒吸一口冷气，认真分析了一遍大部分环境的情况之后，发现没有想象的那么糟糕，这些变更类的对象基本都是周期表。
而反过来，从安全的角度来说，我们不可避免会出现一些问题，只要是和人相关的，那就肯定会存在潜在问题。所以就可以寄希望于完善的机制和流程来补上这一个环节。
整体来说是下面的关系。
我们在数据库中存在着周期表和普通表，对表的删除操作一定是危险的，所以我们可以在现有的机制中尽可能不要涉及这类操作，而采用一个归档库，或者我叫做回收站更贴切一些。
这个回收站和我们Windows里面的使用方式是类似的，和Oracle中的回收站recyclebin也是一脉相承的。
这里涉及几个问题。
1）对于回收站中文件的清理，应该是周期性和被动型任务并存，即可以周期性扫描，同时按照阈值的方式来进行清理，比如阈值超过80%就应该启动自动的清理扫描任务。
2）如果一个表在同一段时间变更了多次，那么在回收站中就会存在多个表的数据副本，如何去还原是一个需要考虑设计的重要问题。
3）既然drop操作是敏感的，我们不妨就彻底的在线上环境中去除删除操作，取而代之以指定的存储过程等形式来集成对接。
4）从生命周期的角度来看，我们需要对这些敏感操作生成相应的日志信息。
而已回收站的维度来说，我们可以按照空间大小和变更时间进行综合计算得到一个更合适的处理方式。
