专栏名称: 51CTO技术栈
有趣 | 有料 | 有内涵,为您提供最优质的内容,愿我们一起悦享技术,成就人生。
目录
相关文章推荐
51好读  ›  专栏  ›  51CTO技术栈

牛批!一张6000w数据表的查询优化到0.023s

51CTO技术栈  · 公众号  · 程序员  · 2020-12-17 18:05

正文

我司系统中有一个专门存车流量的库(没有主键),其中一个历史表数据量太大,表空间占据太大,每天有 500w 的数据写入。


图片来自 Pexels

详细需求


老大给我安排了个任务,让我写个按天分表的定时任务,每次把一天的数据转移到按天生成的表中,并删除原表中的数据,主要目的是不想再增长表空间了,保持一个平衡,因为每天删 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 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 结构不存在,MySQL 就只能先扫表筛选出符合条件的数据,再将筛选结果根据 id 排序。这个排序过程就是 filesort。


我们要让 ORDER BY 字句使用索引来避免 filesort(用“避免”可能有些欠妥,某些场景下全表扫描、filesort 未必比走索引慢),以提高查询效率。


进行优化之前我们还需要学会看 SQL 的执行计划(EXPLAIN)分别为(这里着重讲解 type、rows、Extra,其它的这里不做讲解,可自己私下进行了解):
id、select_type、tabletype、possible_keys、key、key_len、ref、rows、Extra

type: 对表访问方式,表示 MySQL 在表中找到所需行的方式,又称“访问类型”。


MySQL 找到数据行的方式,效率排名 NULL>system>const>eq_ref>ref>range>index>All。


range 只检索给定范围的行,使用一个索引来选择行,一般是在 where 中出现 between、、in 等查询,范围扫描好于全表扫描。







请到「今天看啥」查看全文