近日，由于部门数据库读库空间过小，提出删除掉两个月之前日志表的分区（数据库分区是按时间月分区），记述如下：
上网搜索资料发现删除表分区大概分这么几步：
1、查询需要删除掉的分区：
select t.DATAPARTITIONNAME from syscat.datapartitions t where tabname = '?' with ur
syscat.datapartitions表存放所有的分区，根据表名时间查询出所要删除的分区名。
2、detach分区到一张临时表（该操作会创建临时表，临时表已存在会报错），detach是分离分区的意思：
alter table 表名 detach partition 分区名 into table 临时表名；
3、最后再drop掉临时表。
然后我就代码：
1）据时间、表名查出要删除的分区名，存在list；
2）遍历这个list，循环中先detach分区，再删除临时表。
PS：问题来了，测试中发现drop临时表的时候会报错，报该临时表有分区数据再往里面迁，这里我就怀疑detach操作是异步的了，上网一看相关资料，果不其然。
原来detach操作会先将syscat.datapartitions表中的分区改名，但是所属表名不会改，然后将status状态打为L，表明该分区正在迁移中。
于是我代码先根据表名判断存不存在status为L的数据，没有再进行删表，本地测试成功，批量删除分区成功。然而一放到测试环境，测试人员反馈说报错，又是删表出错，这时候奇怪了，不是判断过状态L了吗，而且本地是可以的，纠结了好久！！！最后想通了，detach既然是异步的，那么打上这个L状态也是异步的了，还没打我后续代码就开心的来判断L状态进行删表了。。。幹！！！那搞这个状态有个屁用。
后面我给了两种方案：
1、设置休眠 Thread.sleep(),由于这个时间不好把控，而且我们库表都是有很多分表的，粗粗估计了下，要删除的分区大概是3张总表*72张分表*40个分区，每个停个100毫秒就耗时很大了，故此方案pass。（不考虑用线程并发，因为DBA不允许。。）
2、递归删表 直至成功
public void drop(表名){
try{
删表操作
}catch(Exception e){
drop();
}
}
其实第二种方法是可行的，没办法，代码评审被否掉，于是给了第三种方案：
3、搞两个定时任务
1）先detach分区 分离到拼接的临时表：tmp+表名+分区名，然后新建一张表，存这些被分离的临时表名字，这张表有三个字段：临时表名、状态（删除，未删除）、更新时间
2）然后过段时间，去做删除临时表操作，删完将临删除状态更新为已删除，做了个查询功能监控待删除这张表。