我司系统中有一个专门存车流量的库（没有主键），其中一个历史表数据量太大，表空间占据太大，每天有 500w 的数据写入。
详细需求
老大给我安排了个任务，让我写个按天分表的定时任务，每次把一天的数据转移到按天生成的表中，并删除原表中的数据，主要目的是不想再增长表空间了，保持一个平衡，因为每天删 500w 也会加 500w。
表空间和数据量如下图：
实现思路
/**
* 转移数据 每天凌晨3点 每次只能转移一天的数据
*/
@Scheduled(cron = "0 0 3 * * ?")
public void dataTransfer()throws Exception{
System.out.println("定时器开始运行------------------------------------------");
String tabaleName = "XXX";
String isTable = getTableName(tabaleName);
// 当返回为空时,代表该表不存在,则创建
if(ObjectUtils.isNull(isTable)){
createHistoryDate(names);
}
// 得到最远的时间段
Map<String, Object> orderTime = orderByTime();
// 得到开始和结束时间
if(SysFun.isNotEmpty(orderTime) && orderTime.size() > 0){
orderTime.put("startTime",startTime);
orderTime.put("endTime",endTime);
orderTime.put("tableName",tabaleName);
int i=0;
for (;;) {
System.out.println("进入循环");
// 转移数据
int rst = dataTransfer(orderTime);
// 删除重复数据
int delt = deleteDataTransfer(orderTime);
// 当今天数据转移完成时,退出本次循环
if(rst<=0 && delt <=0){
break;
}
i++;
System.out.println("转移数据表为："+tabaleName+" 转移数据次数: "+i);
}
}
System.out.println("定时器结束运行------------------------------------------");
}
心路历程
方法完成之后，上周五去服务器正式实测，实测时方法用 @PostConstruct 修饰，会在服务器加载 Servlet 的时候运行，并且只会被服务器执行一次。
当时控制台打印：（“定时器开始运行”）卡住，去库中看到表已成功创建。
开始以为是某个地方异常了，后面逐一打印步骤发现是得到最远时间段是卡住了，也就是被一条 SQL 查询卡住了（直接用这条 SQL 去库里查询 300s+ 也没查询出来）。
然后维护这个库的小伙跟我说：要不直接 limit 1 吧，它的插入是根据时间顺序插入的，当时也想到了会出问题，时间顺序肯定不可能完全按照顺序写入。
周末程序走了 2 天果然有问题，如图：
limit 1 是行不通了，那就只能来查询优化了，讲查询优化之前，先说说为什么我们使用ORDER BY 为什么会这么慢？
深入分析
MySQL 有两种方式可以实现 ORDER BY 这里只做简单介绍：
①通过索引扫描生成有序的结果 举个例子。
select * from history order by id
MySQL 会直接遍历上图 id 索引的叶子节点链表，不需要进行额外的排序操作。这就是用索引扫描来排序。
②使用文件排序（filesort）
但如果 id 字段没有任何索引，上图的 B+Tree 结构不存在，MySQL 就只能先扫表筛选出符合条件的数据，再将筛选结果根据 id 排序。这个排序过程就是 filesort。
我们要让 ORDER BY 字句使用索引来避免 filesort（用“避免”可能有些欠妥，某些场景下全表扫描、filesort 未必比走索引慢），以提高查询效率。
id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra
type：对表访问方式，表示 MySQL 在表中找到所需行的方式，又称“访问类型”。
MySQL 找到数据行的方式，效率排名 NULL>system>const>eq_ref>ref>range>index>All。
range 只检索给定范围的行，使用一个索引来选择行，一般是在 where 中出现 between、<、>、in 等查询，范围扫描好于全表扫描。
index Full Index Scan，Index 与 All 区别为 index 类型只遍历索引树。
通常比 All 快，因为索引文件通常比数据文件小。也就是说，虽然 all 和 index 都是读全表，但是 index 是从索引中读取的，而 all 是从硬盘读取的。
ALL Full Table Scan，将遍历全表以找到匹配的行。
rows：根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数，也就是说，用的越少越好。
extra：包含不适合在其他列中显式但十分重要的额外信息。
Using Index：表示相应的 select 操作中使用了覆盖索引（Covering Index），避免访问了表的数据行，效率不错。
如果同时出现 using where，表明索引被用来执行索引键值的查找；如果没有同时出现 using where，表明索引用来读取数据而非执行查找动作。
Using filesort：当 Query 中包含 order by 操作，而且无法利用索引完成的排序操作称为“文件排序”。
下面我们通过一张真实数据图来分析：
EXPLAIN SELECT updateTime FROM historydata ORDER BY updateTime LIMIT 1
通过我们那种查询是没有办法命中索引的，遵循最左原则，为 updateTime 新建一个普通索引（index）NORMAL：
添加索引的过程中再提一嘴：因为这个历史库时时刻刻都有数据写入，所以我当时建索引时担心锁表。
后面查询相关资料就知道了，MySQL 5.6 之后的版本不影响读写，不会锁表，前提存储引擎为 InnoDB，MyISAM 加索引锁表，读写会全部堵塞。
结合执行计划分析该数据，优化就到这了，优化过后这几天定时程序异常的稳，每天定时 500w 数据的转移和删除，也算是解决了。
结尾
在公众号菜单中可自行获取专属架构视频资料，包括不限于 java架构、python系列、人工智能系列、架构系列，以及最新面试、小程序、大前端均无私奉献，你会感谢我的哈
往期热门文章：
1，架构的本质：如何打造一个有序的系统？
2，
分布式高可靠之负载均衡，今天看了你肯定会
3，
分布式数据之缓存技术，一起来揭开其神秘面纱
4，分布式数据复制技术，今天就教你真正分身术
5，
数据分布方式之哈希与一致性哈希，我就是个神算子
6
，分布式存储系统三要素，掌握这些就离成功不远了
7
，想要设计一个好的分布式系统，必须搞定这个理论
8
，
分布式通信技术之发布订阅，干货满满
9，
分布式通信技术之远程调用：RPC
10
，秒杀系统每秒上万次下单请求，我们该怎么去设计
本文分享自微信公众号 - 架构师修炼（jiagouxiulian）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/3647019/blog/4838198