MariaDB能否用CONCAT/GROUP_CONCAT拼接拆分存储的LONGBLOB数据

方案1：直接通过SQL实现 #

• 可行性：可以实现，主流关系型数据库都支持行数据拼接的内置函数，核心是要保证分片按存储顺序拼接：
  • MySQL实现示例：需要先调整临时会话参数避免长度限制，再用GROUP_CONCAT拼接：

    -- 临时调整当前会话的长度限制，数值要超过你要拼接的文件总大小
    SET SESSION group_concat_max_len = 2000000000;
    SET SESSION max_allowed_packet = 2000000000;
    -- 按分片序号拼接，假设你的分片表名为file_chunks，有文件标识字段file_id、分片序号字段chunk_idx、存储二进制的字段blob_content
    SELECT GROUP_CONCAT(blob_content ORDER BY chunk_idx ASC SEPARATOR '') AS full_blob
    FROM file_chunks
    WHERE file_id = '你的文件唯一ID'
    GROUP BY file_id;
    

  • 其他数据库对应函数：PostgreSQL用string_agg(blob_content::text, '' ORDER BY chunk_idx)::bytea，Oracle用LISTAGG或UTL_RAW.CONCAT组合实现
• 弊端：
  • 需要调整数据库参数，生产环境通常不允许随意修改group_concat_max_len、max_allowed_packet这类全局/会话参数
  • 大体积结果查询会占用极高的数据库CPU、内存和IO资源，容易影响其他正常业务请求
  • 数据库拼接出错后排查难度高，很难定位是哪个分片读取异常
  • 语法不通用，切换数据库后需要重写查询逻辑

方案2：业务代码中拼接 #

• 可行性：是更推荐的实现方式，实现逻辑非常简单：
  1. 按分片序号从小到大查询出对应文件的全部5条记录
  2. 按顺序将每条记录的LONGBLOB内容追加到输出流/内存缓冲区/本地文件中即可
• 优势：
  • 不需要修改任何数据库配置，不受数据库参数限制
  • 资源占用可控，不需要一次性加载整个1.17GB文件到内存，可以边查边写，内存占用仅为单个分片的大小
  • 便于校验，每个分片读取后可以单独做哈希校验，拼接完成后也可以对完整文件做完整性校验，出问题容易定位
  • 完全不依赖数据库特性，不管使用什么数据库逻辑都通用，后续维护成本极低

最终建议 #

如果是临时需求、只需要拼接少量文件，可以用SQL方案临时调整参数实现；如果是线上业务的常规功能，优先选择业务代码实现，稳定性和可维护性都远高于SQL方案。

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