一个MySQL数据需求的引导

这是学习笔记的第 1981 篇文章

今天和同事聊一个需求，大概就几分钟的时间，突然发现这个过程还是值得总结的，后期也会把这样的一些需求讨论过程记录下来，能够提炼成一套方法论。

同事的需求有三个问题：

1）现在有一个业务的表数据量在千万左右，如果放在目前的配置库里面，是否合适，是否有其他的风险

2）这个表的数据是周期性存在的，频率是一个月一更新，从数据处理上，这个月处理之后，下个月处理前要先把表里的数据清理掉，这个清理的代价怎么衡量

3）表里的数据在交付后，需要对数据做业务流程处理批量update变更，有没有好的方案。

整个流程如下：

对于这个方案，我们不是按部就班，而是在聊的过程中逐步对于业务的了解，然后重新设计。

第一点，从数据规模上来说，这个数据量本身不是问题，但是这个问题比较模糊，而且需求出发点不是很清晰，我们暂且跳过。

第二点，因为数据统计部要批量录入数据，而录入数据前，要删除已有的数据，那么这个数据清理工作怎么做，delete是显然不行的，因为这个代价太高，而如果使用truncate和drop，那么这个操作本身没有问题，但是权限太高，DBA在线上的这类操作都要慎之又慎，如果开放权限给业务方，那么一旦操作失误，后果不堪设想，所以在这一点上，我明确表明了功能的可行性，但是还存在一些疑虑，当然我们也可以使用其他的方案来补充，比如把drop操作转换为alter操作，即把这个表做rename操作，移动到另外一个数据库中，如果对alter权限敏感，可以提供一个存储过程的方式来处理也可以，当然在脑海中闪现了一系列的方案之后，我选择了待确认的方式。

第三点，这个表里的数据批量变更，业务同学问我select *from test_data where id >xxx limit 2000;这种处理方式效率怎么样，问到这里我是庆幸需求算是聊到地方了，这个操作是非常不建议的，因为这种情况下是明显不走索引的，对于一个千万的大表来说，这类操作的代价太高，而继续沟通，发现他使用limit的方式是根据id的下标来浮动，通过多次批量的更新来更新这张千万级别的表，因为这类操作的频率一月只有一次，我对于这类操作的一种建议就是使用select *from test_data where id between xxxx and xxxx+2000的处理方式，这种情况下是通过索引的方式来联动变更，效率相对会高一些。

而到了这里，整体的需求基本明确了，我们再来看看前面两个问题，到了这个阶段，把前两个问题整合在一起，就可以有一个初步的答案了。

第一个问题，虽然数据库中支撑千万数据量的表是没有问题的，但是这个库是配置库，配置库的数据量都是很小，而且对于变动敏感的。如果表里的数据变动很大，而配置库中基本就是数据查询，变更都很少，这显然是和配置库的属性不符合的，所以在这里我建议重新创建一个业务数据库。

第二个问题，业务同学提到每个月需要做一次这样的数据处理，对于旧表的数据清理，怎么做才是最优雅的方式，考虑到权限和操作复杂度，结合业务特点，因为这个操作频率是每个月一次，我建议是创建一张周期表，比如test_data_201905, test_data_201906这样的形式，统计部门在录入数据的时候就写入到test_data_201905这张表里面，下个月的时候就录入到test_data_201906里面，这样test_data_201905这张表的数据就可以避免做这个清理了，而这个清理工作我们可以转为延迟的操作，比如一个月的月底删除上个月的或者隔两个月做一次清理，设置成系统定时任务，这样一来统计部门只需要录入数据，业务部门只需要变更数据，不会存在明显的数据风险，流程如下图所示。

这样一来我就可以对权限做到控制，即只对统计部门开放select,insert权限，而对业务部门开放，select,update这样的权限组合，当然也可以适当调整，基本的原则是delete权限能不给就不给，DDL权限要全面回收。

所以我们DBA处理需求不是单一的执行，而是需要对需求做到引导，什么该做，什么不该做，有哪些解决方案，这些是我们在需求沟通中可以灵活变通的。