text/clob字段不可用于group by，因语义不可控且主流数据库均直接报错；应优先用业务字段分组，若必须按内容前缀聚类，需substring截取后cast为char并建前缀索引。
因为数据库明确禁止——不是性能差，而是语义不可控、比较行为无法定义。
GROUP BY TEXT/CLOB 会直接报错的具体表现
几乎所有主流数据库都拒绝执行这类语句：
- MySQL 报
ERROR 1167: Key column 'content' doesn't exist in table或Unsupported type for key（8.0.19+ 直接禁用） - PostgreSQL 报
cannot use type text in GROUP BY或隐式转换失败（如对BYTEA用SUBSTRING不加CONVERT_FROM） - SQL Server 报
Cannot use text, ntext or image data types in the GROUP BY clause - 达梦（DM8）报
[-6116]: 无法比较的数据类型，即使只GROUP BY id但表里存在CLOB字段也会触发（需注意：ENABLE_BLOB_CMP_FLAG=1 仅支持ORDER BY和DISTINCT，不支持GROUP BY）
为什么不能靠函数“绕过”，比如 MD5(content) 或 SUBSTRING(content,1,255)
看似能跑通的写法，实际埋着三类硬伤：
-
MD5(content)在content IS NULL时返回NULL，所有空值被强制归为一组——你本想区分“内容为空”和“字段缺失”，结果全混了 -
SUBSTRING(content, 1, 100)在 PostgreSQL 中若原字段是BYTEA，必须先CONVERT_FROM(blob_col, 'UTF8')，否则类型不匹配报错 -
HASHBYTES('SHA2_256', col)在 SQL Server 中对超过 8000 字节的VARBINARY(MAX)会静默截断，不同长文本可能产出相同哈希值，分组结果失真
真正可行的替代方案：什么时候该截、怎么截、截完还缺什么
如果业务上真需要按内容前缀聚类（例如日志摘要去重、反馈关键词归档），必须显式截取 + 类型转换：
- 用
SUBSTRING(content, 1, 255)，不用LEFT(content, 255)——后者在某些 MySQL 版本返回BLOB类型，仍无法分组 - 必须
CAST(SUBSTRING(content, 1, 255) AS CHAR(255))，只写CAST(content AS CHAR)会失败 - 加前缀索引提升性能：
ALTER TABLE logs ADD KEY idx_note_prefix (note(255));，否则每次SUBSTRING都是全表扫描 - 但要注意：255 是安全上限，不是业务长度——若内容在第 256 字符才出现差异，截断后就无法区分
最常被忽略的一点：你其实不该对 TEXT 分组
绝大多数情况下，想 GROUP BY content 暴露的是设计问题：
-
TEXT字段本质是“非结构化附属信息”，不是分组维度；主键、业务 ID、状态码、时间范围才是合理分组依据 - 用
GROUP BY SUBSTRING(content,1,255)做统计，等于默认“前 255 字相同 = 内容相同”，但现实中两段不同描述完全可能前缀一致 - 真正要的是“每组取最新一条记录”？那是窗口函数的场景，不是
GROUP BY的职责
