MySQL 不允许直接对 CLOB/BLOB/TEXT 字段 GROUP BY，8.0.19+ 明确报错 Unsupported type for key；5.7+ 常因 ONLY_FULL_GROUP_BY 模式叠加类型限制触发 Expression #X 报错；必须用 SUBSTRING(content, 1, 255) + CAST(... AS CHAR(255)) 转为可分组类型，或重构逻辑改用业务字段分组。
MySQL 中 GROUP BY 遇到 CLOB/BLOB 字段直接报错
MySQL 不允许直接对 CLOB、TEXT、BLOB 类型字段做 GROUP BY，8.0.19+ 版本会明确报错 Unsupported type for key；5.7+ 则常因 ONLY_FULL_GROUP_BY 模式叠加字段不可分组而触发 Expression #X of SELECT list is not in GROUP BY clause。这不是配置问题，是类型限制本身。
常见错误写法：SELECT user_id, content FROM posts GROUP BY content;——哪怕 content 是 TEXT，也会被拒绝。
- 先确认是否真卡在模式上：
SELECT @@sql_mode;看是否含ONLY_FULL_GROUP_BY - 临时绕过（仅调试）：
SET SESSION sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));，但不解决TEXT无法分组的本质 -
CAST(content AS CHAR)无效：MySQL 对TEXT的裸 CAST 仍返回不可分组类型 - 必须显式截断再转：
SUBSTRING(content, 1, 255)后再CAST(... AS CHAR(255))，否则可能隐式转为BLOB
用 SUBSTRING + CAST 实现可分组前缀
业务上若真需按内容相似性聚类（如日志归档、反馈摘要分组），只能取“可控前缀”替代全量内容。安全长度选 255，兼顾兼容性与区分度。
正确写法示例：SELECT CAST(SUBSTRING(note, 1, 255) AS CHAR(255)) AS note_prefix, COUNT(*) FROM logs GROUP BY note_prefix;
- 别用
LEFT(note, 255)：某些 MySQL 版本对TEXT返回BLOB，依然无法分组 - 长度不能随意设大：超 255 可能触发隐式转换失败，4000 虽是
VARCHAR上限，但实际索引和内存开销剧增 - 如果字段名带 schema 或 alias，CAST 必须包裹最内层表达式，如
CAST(SUBSTRING(t.content, 1, 255) AS CHAR(255))
哈希转换（MD5/SHA1）不是万能解法
有人想用 MD5(content) 分组来规避长度限制，但要注意：哈希值只是内容指纹，相同哈希不保证内容相同（极低概率碰撞），且完全丧失语义可读性。
更关键的是性能陷阱：MD5(content) 无法走索引，全表计算哈希 + 分组，大数据量下比 SUBSTRING 更慢。
- 若坚持哈希，优先用
MD5(SUBSTRING(content, 1, 1000))控制输入长度，避免长文本拖垮计算 -
SHA1和MD5在 MySQL 中返回的是 32/40 位十六进制字符串，可直接用于GROUP BY，但仍是无索引操作 - 哈希后无法反查原文，只适合去重统计，不适合需要展示“典型内容”的报表场景
真正该做的：重构分组逻辑，避开 TEXT/BLOB
绝大多数报错背后，是设计误判：把描述性字段当主键用。CLOB/BLOB 应是附属信息，分组应基于业务标识字段（如 user_id、category_id、log_type）。
例如：SELECT user_id, COUNT(*), MAX(created_at) FROM posts GROUP BY user_id; —— 这才是合理分组。
- 如果需要“按内容相似性分组”，说明缺少中间维度：应提前提取关键词、打标签、或存入专用摘要字段（
VARCHAR(500)），而非硬刚原始 CLOB - 加前缀索引可缓解性能：执行
ALTER TABLE logs ADD KEY idx_note_prefix (note(255));，让SUBSTRING(note, 1, 255)查询有机会命中 - Oracle 或 PostgreSQL 用户注意：它们对 CLOB 分组限制不同（如 Oracle 允许
DBMS_LOB.SUBSTR），但原理一致——必须显式降维，不能裸用大对象
最易被忽略的一点：SUBSTRING 截断后，两条不同内容可能变成相同前缀，导致误合并。上线前务必用真实数据抽样验证截断长度是否足够区分业务场景中的关键差异。
