最近遇到一个导出Excel文件时报超时的问题,经过排查,最终发现是MySQL索引失效导致的。
排查思路
Excel导出这个功能是通过异步实现的:
前端生成一个asyncKey,后端接收到这个asyncKey以后将其存入Redis缓存,并在value中放异步导出的进度和完成信息,前端再发送轮询请求去获取这个进度信息,并更新到进度条;后端的逻辑是先将数据查询出来组装好,再通过POI方式写入到Excel文档中,生成的Excel文件放到FastDFS文件服务器,最后把文件服务器中的文件地址返回给浏览器,供浏览器下载。
- 首先是怀疑Excel导出数据量过大,服务器承受不了导致超时,但一问人家测试人员才导出5K+的数据,完全不至于;
- 接着怀疑导出没有使用异步进程,没有使用多线程,查看源代码里使用了
CompletableFuture.supplyAsync()
来支持异步; - 接下来只能看日志排查了,通过监听导出服务的日志,截取出sql查询语句,准备去试下查询语句执行时长,将sql拷贝到数据库里执行查询,发现数据库报出timeout错误;
问题所在
既然已经定位到是sql语句查询出现超时,那问题已经解决了一半。接下来就看是sql语句本身写法有问题,还是其他比如没有索引导致的效率问题。
sql语句中出现了多次left join
的关联查询,我们项目中主子表通过id做关联,但是不会设置为外键(至于不设置外键的原因可查询下资料,阿里的编码规范里不使用外键是强制的),而是将关联字段设置为索引。所以首先想到是id字段上没有加索引导致查询慢,通过show index from table
查看创建的索引,发现id字段是有加索引的,这就奇怪了…
通过Navicat for MySQL执行sql语句,点击解释查看执行计划,耗时最长的还是跟id相关的join语句,最后是同事帮忙看出来问题,原来是主表id数据类型是bigint, 而到了子表里将主表id存为了varchar类型,字段类型不一致就导致了索引失效。
最后需要将主子表中字段类型改为一致,因为表里数据已经上万,数据库改数据类型消耗的时间也不短,也需要谨慎操作,至此查询效率问题就解决了。