LOB字段不能直接用于GROUP BY，因语义不可控且数据库普遍禁止；需提取业务字段或预存哈希值替代，避免截断、隐式转换及性能风险。
LOB字段不能直接出现在GROUP BY中
绝大多数主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）明确禁止将LOB类型字段（如 TEXT、MEDIUMTEXT、CLOB、XML、JSON、VARBINARY(MAX)）直接写进 GROUP BY 子句，会直接报语法错误或类型不支持错误。根本原因不是性能问题，而是语义不可控：LOB值通常超长、不可索引、无法高效比较，数据库无法保证分组时的哈希/排序行为稳定可靠。
试图用函数包装LOB做分组仍可能失败
有人尝试绕过限制，比如写 GROUP BY SUBSTRING(content, 1, 100) 或 GROUP BY MD5(content)，但这存在三类风险：
- MySQL 8.0+ 对
MD5()返回的CHAR(32)允许分组，但若content为NULL，MD5(NULL)返回NULL，所有 NULL 被归为一组——可能把本该区分的空内容和缺失内容混在一起 - PostgreSQL 中
SUBSTRING(blob_col, 1, 100)若原字段是BYTEA，需先CONVERT_FROM(blob_col, 'UTF8')，否则报错“cannot cast type bytea to text” - SQL Server 对
VARBINARY(MAX)计算HASHBYTES('SHA2_256', col)是可行的，但该函数对 > 8000 字节输入会静默截断，导致不同长文本产生相同哈希值
真正安全的替代方案只有两种
不要在分组逻辑里依赖 LOB 值本身。必须把业务意图拆解清楚：
- 如果目标是「按文档类型分组」：提取并持久化一个
doc_type VARCHAR(20)字段，用它分组，而不是解析content的前几个字节 - 如果目标是「找内容重复的记录」：在应用层或 ETL 阶段预计算并存储
content_hash CHAR(64)（例如 SHA2-512），确保完整计算、非截断、可索引，再对这个字段分组
临时用子查询 + ROW_NUMBER() OVER (PARTITION BY ...) 标记重复，比强行在 GROUP BY 里拖拽 LOB 更可控——毕竟分组只是手段，识别重复才是目的。
容易被忽略的隐式转换陷阱
某些 ORM 或中间件（如旧版 MyBatis、Django ORM）在拼接 SQL 时，若你写了 GROUP BY content，它可能自动帮你转成 GROUP BY CAST(content AS VARCHAR(8000))。这看似“能跑”，但实际埋了雷：
- MySQL 中
CAST(TEXT AS CHAR)默认长度是 1024，超出部分被无声截断 - SQL Server 中
CAST(VARBINARY(MAX) AS VARCHAR)遇到非 UTF-8 字节会转成?，不同二进制数据可能映射为相同字符串 - 这种转换结果无法走索引，分组性能随数据量陡增，且结果不可复现
查执行计划时看到 CONVERT_IMPLICIT 或 CAST 节点，就得立刻停手——这不是兼容性补丁，是逻辑漏洞。
