用SUBSTRING或LEFT分组可行但需谨慎处理边界：必须防范NULL、空格、越界截取三类问题，推荐TRIM+IFNULL+LEAST组合防护，并严格过滤脏数据。
直接说结论：用 SUBSTRING 或 LEFT 做分组是可行的，但必须确保截取逻辑稳定、无歧义，否则分组结果会错乱甚至漏数据。
为什么不能直接在 GROUP BY 里写 SUBSTRING(field, 1, 3)？
MySQL 允许在 GROUP BY 中使用表达式，包括 SUBSTRING 和 LEFT，但问题常出在「隐式类型转换」和「NULL 处理」上：
- 如果被截取字段是
NULL，SUBSTRING(NULL, 1, 3)仍返回NULL，而所有NULL会被归为同一组——这容易掩盖真实数据分布 - 若字段含前导/尾随空格，
LEFT(name, 2)可能截到空格，导致本该同组的记录被拆开 -
SUBSTRING(str, pos)中pos超出长度时返回空字符串''，而非报错，容易和真实空值混淆
LEFT 和 SUBSTRING 在分组场景下的实际差异
二者在分组中功能高度重叠，但行为细节不同：
-
LEFT(str, n)更适合「固定长度前缀」场景，比如取城市编码前两位：LEFT(city_code, 2) -
SUBSTRING(str, 1, n)等价于LEFT，但SUBSTRING(str, -n)支持倒取（如取后三位），LEFT不支持 - 当需要动态起始位置（比如从某个字符后开始截），只能用
SUBSTRING配合LOCATE，例如：SUBSTRING(url, LOCATE('://', url) + 3) - 性能上无显著差别，但
LEFT语义更直白，可读性略高
分组时必须处理的三个边界情况
不加防护的截取分组极易翻车，这几个点必须显式应对：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
COALESCE或IFNULL包裹截取表达式，避免NULL干扰分组：GROUP BY IFNULL(LEFT(tag, 4), 'unknown') - 对源字段先
TRIM，再截取，防止空格污染：LEFT(TRIM(name), 3) - 确认截取长度不超过字段最大可能长度，否则短字段会补空——可用
LEAST控制上限：LEFT(title, LEAST(LENGTH(title), 10))
一个真实可用的分组查询示例
假设要按邮箱域名前缀（如 gmail.com → gmail）统计用户数，且需排除无效邮箱：
SELECT
SUBSTRING_INDEX(email, '@', -1) AS domain,
SUBSTRING_INDEX(SUBSTRING_INDEX(email, '@', -1), '.', 1) AS domain_prefix,
COUNT(*) AS cnt
FROM users
WHERE email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$'
AND email IS NOT NULL
GROUP BY domain_prefix;
这里用了两次 SUBSTRING_INDEX：第一次取 @ 后部分，第二次取该部分第一个 . 前的内容。关键点在于 WHERE 过滤掉了格式异常的数据——没这步，SUBSTRING_INDEX 遇到不含 @ 的字段会原样返回，导致分组混乱。
真正难的不是函数怎么写，而是你得清楚字段里到底有什么脏数据。截取分组一旦跑起来，错误往往静默发生，等发现时已影响报表或下游逻辑。
