如何加速从MySQL获取Base64格式图片的查询速度？

先看一下你的原始查询和EXPLAIN分析结果：

原始查询 #

SELECT ID_MENU_PRP, ID_PLUREP, CODICE_PRP, DESC_S_PRP, UM_PRP, DESC_T_PRP, PRE_PRP, img.IMG_IMG 
FROM vo_plurep plu 
INNER JOIN vo_images img ON plu.ID_PLUREP = img.ID_PLUREP_IMG AND img.ORDER_IMG = 0 
WHERE plu.ATTIVO_PRP = 'True';

EXPLAIN结果 #

{ "query_block": { "select_id": 1, "cost_info": { "query_cost": "621.57" }, "ordering_operation": { "using_filesort": true, "nested_loop": [ { "table": { "table_name": "plu", "access_type": "ref", "possible_keys": [ "PRIMARY", "UNICA", "ID_MENU_PRP_idx", "ATTIVO_PRP_idx" ], "key": "ATTIVO_PRP_idx", "used_key_parts": [ "ATTIVO_PRP" ], "key_length": "753", "ref": [ "const" ], "rows_examined_per_scan": 392, "rows_produced_per_join": 392, "filtered": "100.00", "cost_info": { "read_cost": "14.25", "eval_cost": "39.20", "prefix_cost": "53.45", "data_read_per_join": "7M" }, "used_columns": [ "ID_PLUREP", "ID_MENU_PRP", "MENU_PRP", "CODICE_PRP", "DESC_T_PRP", "DESC_S_PRP", "ATTIVO_PRP", "UM_PRP", "PRE_PRP" ], "attached_condition": "(`02288660356`.`plu`.`ID_MENU_PRP` is not null)" } }, { "table": { "table_name": "menu", "access_type": "eq_ref", "possible_keys": [ "PRIMARY", "UNICA", "ID_CFG_MEN_idx" ], "key": "PRIMARY", "used_key_parts": [ "ID_MENU" ], "key_length": "4", "ref": [ "02288660356.plu.ID_MENU_PRP" ], "rows_examined_per_scan": 1, "rows_produced_per_join": 392, "filtered": "100.00", "cost_info": { "read_cost": "98.00", "eval_cost": "39.20", "prefix_cost": "190.65", "data_read_per_join": "6M" }, "used_columns": [ "ID_MENU", "ID_CFG_MEN" ], "attached_condition": "(`02288660356`.`menu`.`ID_CFG_MEN` = 20)" } }, { "table": { "table_name": "img", "access_type": "ref", "possible_keys": [ "ID_PLUREP_IMG" ], "key": "ID_PLUREP_IMG", "used_key_parts": [ "ID_PLUREP_IMG" ], "key_length": "5", "ref": [ "02288660356.plu.ID_PLUREP" ], "rows_examined_per_scan": 1, "rows_produced_per_join": 39, "filtered": "100.00", "cost_info": { "read_cost": "391.72", "eval_cost": "3.92", "prefix_cost": "621.57", "data_read_per_join": "30K" }, "used_columns": [ "ID_IMAGES", "ID_PLUREP_IMG", "IMG_IMG", "ORDER_IMG" ], "attached_condition": "(`02288660356`.`img`.`ORDER_IMG` = 0)" } } ] } } }

结合你的情况，核心问题是大体积的img.IMG_IMG字段拖慢了数据读取和传输——即使查询被缓存，大响应体的传输时间还是占了请求耗时的大头。我给你几个针对性的优化方案：

1. 拆分接口，分离图片获取 #

不要在主条目接口里返回图片数据，单独做一个获取单张图片的接口，比如GET /api/items/{itemId}/image：

• 主接口只返回条目基本信息，查询速度会显著提升（不用加载大MEDIUMTEXT字段）
• 客户端可以按需加载图片，减少不必要的带宽消耗
• 图片接口可以单独设置长缓存时间，进一步降低重复请求的耗时

2. 数据库存储优化：把图片移出数据库 #

用MEDIUMTEXT存大图片本身就不是最优实践，数据库更适合存储结构化数据。建议：

• 将图片文件存储到文件系统或者对象存储（比如本地磁盘、云存储服务）
• 数据库里只存储图片的访问路径或URL
• 这样读取图片时直接从文件系统读取，比从数据库读取大文本快得多，还能配合CDN加速图片访问

3. 数据库索引优化 #

针对你的图片查询逻辑，创建一个联合索引来加速匹配：

CREATE INDEX idx_img_plurep_order ON vo_images (ID_PLUREP_IMG, ORDER_IMG);

这个索引可以让数据库直接定位到每个条目对应的ORDER_IMG=0的图片，避免不必要的扫描。另外，ATTIVO_PRP字段是字符串类型（值为'True'），如果这个字段的基数很低（大部分条目都是激活状态），当前的ATTIVO_PRP_idx索引效率有限，考虑换成布尔类型字段，或者结合ID_MENU_PRP创建联合索引，进一步优化主表查询。

4. 启用API响应压缩 #

在WebApi中启用Gzip或Deflate压缩，大文本（尤其是Base64格式的图片）压缩后体积能减少60%以上，大幅缩短传输时间。在WebApi 2中可以通过配置实现：

// 在WebApiConfig.cs中添加
config.MessageHandlers.Insert(0, new ServerCompressionHandler(new GZipCompressionProvider(), new DeflateCompressionProvider()));

5. 消除文件排序（可选优化） #

从EXPLAIN结果看到有using_filesort，虽然当前不是主要瓶颈，但如果你的查询有排序逻辑，可以添加覆盖索引来消除文件排序，进一步提升查询效率。比如如果主查询是按某个字段排序，就把该字段加入到联合索引中。

内容的提问来源于stack exchange，提问作者Kasper Juner