LIKE不能直接用于GROUP BY，必须先用CASE WHEN或字符串函数构造可分组的分类键；WHERE预过滤或计算列承载匹配逻辑，HAVING不可用于原始字段LIKE；注意NULL/空字符串处理与大小写差异。
LIKE不能直接写在GROUP BY里，必须先构造分组键
SQL标准不允许在 GROUP BY 子句中直接使用带通配符的 LIKE 表达式（比如 GROUP BY name LIKE '%admin%'），因为 LIKE 是布尔运算，返回 TRUE/FALSE，不是可分组的值。真正要做的，是把模糊匹配逻辑“固化”成一个可分组的字段——通常是用 CASE WHEN 或字符串截取函数构造出分类标签。
常见场景：把用户邮箱按域名归类（如 @gmail.com、@qq.com）、把产品名按关键词打标（如含“pro”算高端线，“lite”算轻量版）。
- 优先用
SUBSTRING_INDEX(email, '@', -1)（MySQL）或SPLIT_PART(email, '@', 2)（PostgreSQL）提取域名，再GROUP BY该结果 - 若必须靠关键词模糊判断，用
CASE WHEN name LIKE '%pro%' THEN 'pro' WHEN name LIKE '%lite%' THEN 'lite' ELSE 'other' END生成分组列 - 注意大小写：MySQL默认不区分大小写，PostgreSQL和SQL Server默认区分，必要时加
LOWER()统一处理
GROUP BY后无法对原始字段做LIKE过滤，HAVING也不行
HAVING 只能过滤聚合后的结果（如 COUNT(*) > 5），不能回退到原始行去执行 LIKE。如果你写了 HAVING name LIKE '%test%'，多数数据库会报错，因为 name 不在 GROUP BY 列表里，也没有被聚合函数包裹。
正确做法是：把模糊匹配逻辑移到 WHERE 子句（预过滤），或在分组前用计算列承载匹配结果。
- 想只统计含“error”的日志行？先
WHERE message LIKE '%error%'，再GROUP BY level - 想按“是否含error”分两组统计？用
CASE WHEN message LIKE '%error%' THEN 'has_error' ELSE 'no_error' END AS flag，然后GROUP BY flag - 别在
HAVING里写MAX(message) LIKE ...——语义混乱且不可靠，MAX()返回的是字典序最大值，不是原始匹配行
性能敏感时，避免在GROUP BY表达式里反复调用LIKE
如果分组键依赖 LIKE 判断（比如上面的 CASE WHEN），而数据量大，每次分组都要对每行执行多次 LIKE，开销不小。特别是 LIKE '%xxx' 无法走索引，全表扫描不可避免。
优化方向是前置计算、减少重复判断，或改用更高效模式。
- 把常用模糊规则的结果存为冗余列（如
is_pro_version BOOLEAN），并建索引，GROUP BY is_pro_version就快得多 - 用正则替代多层
CASE WHEN LIKE（如 PostgreSQL 的REGEXP_REPLACE(name, '.*?(pro|lite|base).*', '\1')），但注意正则本身也慢 - MySQL 8.0+ 支持函数索引，可对
LOWER(SUBSTRING_INDEX(email, '@', -1))建索引，加速分组
不同数据库对NULL和空字符串的LIKE行为不一致
NULL LIKE '%x%' 永远返回 UNKNOWN（即逻辑假），但 '' LIKE '%x%' 在 MySQL 返回 FALSE，在 PostgreSQL 返回 FALSE，SQL Server 却可能因设置返回 TRUE。这直接影响分组后某组计数是否包含空值。
最稳妥的做法是显式处理边界情况。
- 在
CASE WHEN分组逻辑里加上WHEN name IS NULL THEN 'unknown' WHEN name = '' THEN 'empty' - 避免依赖
LIKE的隐式转换，比如CAST(col AS TEXT) LIKE '%x%'在某些引擎里可能把NULL转成字符串'NULL' - 测试时务必用真实数据中的
NULL和空字符串验证分组结果，别只用非空样本
