关于长文本查询导致接口超时

今天在项目中碰到一个长文本的查询效率的问题，目前还没有找到解决方案，先记录下，有时间再来研究。

问题如下：
在数据库中存着产业链的图片信息，为长文本类型。

画面加载的时候，需要从数据库中获取这些图片信息生成一览。

DB中只有几十条数据，但是由于涉及到长文本，查询速度非常慢（主要是资源下载很慢），接口返回可高达10S以上，导致接口超时。

————————————————————————————————————————

自己的解决方案：

（1）分页，用缓存

在程序中用一个MAP保存所有的图片信息，第一次加载的时候，加载所有的数据，之后的查询都基于这个MAP。新增、修改和删除也同步修改这个MAP。

结果：解决了接口超时。

问题：在数据库中手动改数据，比如删除数据，或修改名称，页面数据同步不到。

————————————————————————————————————————

针对上面问题的解决方案：

（2）设置缓存失效时间

加定时器，设置一段时间自动让缓存失效，去DB中重新取数据。

问题：虽然可以解决DB与页面不一致问题，但是即时性不能保证。

思来想去，也想不到好的方法。还是用回了直接DB分页取数据的方式，设置分页大小为12条，基本解决了接口超时的问题，但是网络不好，或者把分页大小改大的话，还是出现接口超时。

————————————————————————————————————————

2024.9更新

经过两年的技术积累，现在面对这种问题更加从容了。其实数据库下载慢的问题，已经超出了技术解决的范畴，如果非要一次性从数据库取大量数据，慢的问题不可避免。用非技术手段，比如升级数据库硬件，使用更大内存的电脑，使用SSD等，可以一定程度上提高速度，但是却不能完全解决问题，一旦数据量更大，一次全部取出势必还是会出现速度慢的问题。

所以最好的解决方式就是不要一次取那么多数据。这个从设计层面很好解决。将SVG转化为图片文件，上传到OSS上，数据库只保存图片地址，这样在列表加载的时候，只需要返回图片地址而不用取SVG字段，自然速度就快了。至于编辑，因为是用ID查询单个图片的SVG，速度不会慢。

所以技术问题，有时候不一定要用技术手段解决，换一种设计思路，问题根本就不存在了。所以在工作中要注意打开思路，寻找最佳方案，不要将思维局限在技术范畴了。