MySQL 5.7+启用ONLY_FULL_GROUP_BY后，TEXT字段无法直接GROUP BY，因不可索引且长度不确定；需用SUBSTRING(content,1,255)配合CAST(...AS CHAR(255))，并添加前缀索引才能安全高效执行。
MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 模式，真正卡住你的往往不是“类型冲突”，而是字段未满足分组语义约束——CAST 或 CONVERT 本身解决不了这个根本问题，只在极少数场景下能绕过 TEXT/BLOB 的隐式限制。
为什么 CAST(content AS CHAR) 会失败
直接写 CAST(content AS CHAR) 在 MySQL 中仍报错，是因为 TEXT 类型无法被直接 CAST 成可比较的标量类型；8.0.19+ 更是彻底禁止对未截断的 TEXT 做 GROUP BY。错误不是类型转换失败，而是引擎拒绝把不可索引、不可确定长度的值当作分组键。
-
CAST(note AS CHAR)→ 返回 BLOB 类型（仍不可分组） -
CONVERT(note, CHAR)→ 同样不生效，底层逻辑一致 - 真正有效的是先
SUBSTRING(note, 1, 255)再CAST(... AS CHAR(255))
GROUP BY 中用 SUBSTRING + CAST 的实操要点
仅当业务真需按内容前缀聚类（如日志摘要归档、反馈关键词粗筛）时才考虑该方案，且必须控制长度和明确语义。
- 安全长度选
SUBSTRING(content, 1, 255)，避免超长触发隐式截断或报错 - 必须显式指定长度：
CAST(SUBSTRING(content, 1, 255) AS CHAR(255))，不能省略(255) - 别用
LEFT(content, 255)—— 某些版本返回 BLOB，依然无法参与 GROUP BY - 示例：
SELECT CAST(SUBSTRING(note, 1, 255) AS CHAR(255)) AS prefix, COUNT(*) FROM logs GROUP BY prefix;
性能与索引必须同步处理
SUBSTRING + CAST 是计算列，无法走普通索引，大数据量下会全表扫描。
- 必须补上前缀索引：
ALTER TABLE logs ADD KEY idx_note_prefix (note(255)); - 注意：该索引只加速
WHERE note LIKE 'xxx%'或GROUP BY SUBSTRING(note, 1, 255)类查询，对全文模糊匹配无效 - 如果查询中还带
WHERE条件，确保条件字段也建了联合索引，否则 GROUP BY 仍慢
真正该优先做的：避开对 TEXT 字段 GROUP BY
绝大多数报错背后，其实是设计误判——TEXT 应是描述性附属字段，不是分组依据。强行分组会引入歧义（两条不同内容被截成相同前缀就合并了），也掩盖了真实聚合意图。
- 检查是否本该用
user_id、category_id等业务主键分组，而非content - 若需同时展示明细和统计，改用窗口函数：
AVG(salary) OVER (PARTITION BY department) - 若真要基于文本相似性聚类，应移出 SQL，交给 Elasticsearch 或 Python 的文本向量化处理
最易被忽略的一点：哪怕你成功用 CAST + SUBSTRING 跑通了查询，只要没加前缀索引，线上数据一过百万，这条语句就会拖垮整个从库。
