不安全但可用，需处理NULL和越界：SUBSTRING(col,1,5)遇NULL返回NULL，GROUP BY将所有NULL归为一组；短字符串截取返回实际内容而非NULL，LEFT(col,5)语义更清晰；按域名分组应配合LOCATE判断或用SUBSTRING_INDEX；前缀分组无法直接走索引，高频场景需建生成列加索引；大小写和空格影响分组结果，建议前置TRIM和LOWER清洗。
GROUP BY 里直接用 SUBSTRING 安不安全？
不安全，但可用——前提是明确处理 NULL 和越界情况。SUBSTRING(col, 1, 5) 遇到 NULL 返回 NULL，而 GROUP BY 会把所有 NULL 归为一组，容易把“缺失值”和“真实前缀为 NULL 的记录”混在一起。
- 若字段允许 NULL，且业务上要区分“空”和“无数据”，得先用
COALESCE(col, '')或CASE WHEN col IS NULL THEN 'MISSING' ELSE SUBSTRING(col, 1, 5) END -
SUBSTRING(col, 1, 5)中长度超出原字符串时，MySQL/PostgreSQL 返回实际剩余部分，不会报错；但SUBSTRING(col, 10, 5)对只有 3 字符的字段返回空字符串，不是 NULL —— 这可能让分组结果意外多出一行空前缀 - 更稳妥的写法是：
LEFT(col, 5)，它对短字符串直接返回原值，语义更清晰，也避免负索引误用
想按邮箱域名分组，为什么 SUBSTRING + LOCATE 总出错？
因为没处理 '@' 不存在的情况。LOCATE('@', email) 在找不到时返回 0，导致 SUBSTRING(email, 0 + 1) 变成从第 1 位截取，结果等于全字段，而不是预期的 NULL 或空值。
- 必须加判断：
CASE WHEN LOCATE('@', email) > 0 THEN SUBSTRING(email, LOCATE('@', email) + 1) ELSE NULL END - MySQL 可用更简洁的
SUBSTRING_INDEX(email, '@', -1)，它在无 '@' 时返回整字段，仍需额外过滤或NULLIF - SQL Server 要用
CHARINDEX，且SUBSTRING第三个参数不能省略，否则报错；得写成SUBSTRING(email, CHARINDEX('@', email) + 1, LEN(email))
长文本字段 GROUP BY 前缀，能走索引吗？
不能直接走索引——标准 B-tree 索引对 SUBSTRING(col, 1, 8) 这类表达式无效，除非你建了函数索引或前缀索引。
- MySQL 5.7+ 支持生成列：
ALTER TABLE t ADD COLUMN domain VARCHAR(32) STORED AS (SUBSTRING_INDEX(email, '@', -1)); CREATE INDEX idx_domain ON t(domain); - 前缀索引（如
INDEX idx_email_prefix (email(12))）只加速WHERE email LIKE 'abc%'，对GROUP BY LEFT(email, 12)无帮助 - 如果只是临时分析，
GROUP BY SUBSTRING(col, 1, n)没问题；但高频查询必须物化前缀字段，否则每次执行都全表扫描+计算
大小写和空格影响分组结果吗？
影响很大，而且默认行为常被忽略。比如 GROUP BY LOWER(SUBSTRING(name, 1, 4)) 会强制统一，但无法利用索引；而直接 GROUP BY SUBSTRING(name, 1, 4) 则完全取决于字段的 collation。
- 查当前排序规则：
SHOW FULL COLUMNS FROM t LIKE 'name';，看Collation列是utf8mb4_0900_ai_ci（不区分大小写）还是_cs（区分） - 想临时忽略大小写又不想改表结构，可用
GROUP BY SUBSTRING(LOWER(name), 1, 4)，但注意：LOWER() 在 WHERE 中无法走索引，GROUP BY 同理 - 前后空格会导致相同前缀被拆成多组，建议前置清洗：
GROUP BY SUBSTRING(TRIM(name), 1, 4)
