记一次 base64 图片存储引发后端查询接口性能断崖式下降问题全程解析

问题回顾

同事小赵接到客户导入新闻数据要求，由客户提供新闻数据。于是，小赵通过 SQL 脚本入库新闻数据后，发现前台展示新闻特别慢。幸好是晚上凌晨 1 点，用户比较少，处理问题来得及，最终经过一个小时排查问题，原来问题出在这里。。。

问题定位

在小赵导完数据后，测试小赵发现内容管理列表页访问特别慢，加载完数据需要 16 秒左右。

于是我用 F12 打开 chrome 调试工具，发现获取新闻内容列表数据的 API 接口：“getManageArticleList" 接收的数据有 7.1 M，接口响应时间长达 16 秒多，太不正常了。

但是同一个接口换一个查询条件，接收的数据只有 367 KB，响应时间 4.5 秒。

由此，这说明两个问题

第一、API 接口的请求与响应是没问题的

第二、换查询条件后，接口响应时间差距近 12 秒之多，说明接收数据有问题

既然是数据问题，于是在和小赵对比入库前和入库后的新闻数据后，发现问题出在图片 base64 加密存储。

原来，客户提供的文章数据中包含图片，但由于客户原图不在了，只能从别的地方收集新闻时，把包含图片的新闻采用了 base64 加密串给了小赵。这些 base64 加密的图片每张基本上在 1 M 左右，前端一次性分页加载 10 条共 7M 的数据，变慢就不足为怪了。

另外，为什么新闻列表页需要加载图片呢？通过代码走查，发现图片是放在 contentText 字段里面，但是 新闻内容列表

select 分页语句却包含了 contentText 字段，明显 select 语句不合理。

select ..., contenText from article

解决方案

由于时间比较紧迫，本次发版又不涉及服务升级，只能从修改数据入手了。

第一步，用 like 模糊查询存在包含 base64 串的文章，共 34 条记录，数据比较少

select id,title,contenText from article where contenText like '%data:image%'

第二步， 从新闻详情页下载图片，用 fastdfs 分布式文件服务器上传图片后，得到图片的下载地址，替换 img 标签的 src 属性值，格式如下：

group1/M00/00/00/rBIK6VcaP0aARXDSNFHrUgHEviQ663.jpg

10 个人 34 条新闻，花了近 20 分钟，完成 base64 图片地址替换后，问题解决。

base64 编码原理

简单来说就是把一张图片数据加密成一个字符串，使用该字符串代替图像地址，这样的好处是不需要单独用文件服务器存储文件。

问题总结

有时候，问题就出在最显眼的问题描述上，需要有心人去细细琢磨。另外，其实大部分问题都可以在官网上找到相关技术解决方案，却又苦于受英语单词的折磨。