牛批！一张w数据表的查询优化到.s.docxVIP

牛批！一张6000w数据表的查询优化到0.023s 表空间和数据量如下图： 实现思路 实现做法流程，如图： 实现伪代码（删减了部分代码）： ?/**?????*?转移数据?每天凌晨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?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 这里只做简约引见： ①通过索引扫描生成有序的结果 举个例子。 假设 history 表有 id 字段上有主键索引，且 id 目前的范围在 1001-1006 之间，则 id 的索引 B+Tree 如下： 现在当我们想依据 id 从小到大的挨次中取出数据时，执行以下 SQL： ????select?*?from?history?order?by?id MySQL 会直接遍历上图 id 索引的叶子节点链表，不需要进行额外的排序操作。这就是用索引扫描来排序。 ②使用文件排序（filesort） 但假如 id 字段没有任何索引，上图的 B+Tree