having不能直接用regexp过滤分组结果，因其作用对象是聚合后的组，只能使用select中明确出现的列或聚合函数结果；正确做法是用group_concat拼接后配合regexp，或优先用where预过滤。
HAVING 不能直接用 REGEXP 过滤分组结果
这是最常被误解的一点：你不能在 HAVING 子句里写 name REGEXP '李' 来筛选分组。因为 HAVING 的作用对象是「聚合后的组」，而 name 是原始行字段，未参与聚合、也不在 SELECT 列表中时，MySQL 会报错 Unknown column 'name' in 'having clause'。
真正能用在 HAVING 中的，只能是：SELECT 里明确出现的列，或聚合函数（如 COUNT()、GROUP_CONCAT()）的结果。
- ❌ 错误写法：
HAVING name REGEXP '李'（name不是聚合值，也不是分组键） - ✅ 正确方向：把正则逻辑“挪到分组内完成”，再用
HAVING检查该逻辑的聚合结果
用 GROUP_CONCAT + REGEXP 实现分组级正则判断
如果你要查「某个部门里所有员工姓名都含‘李’」或「至少有一个员工姓名含‘李’」这类需求，得靠 GROUP_CONCAT() 把分组内的值拼成字符串，再对这个字符串做 REGEXP。
例如：找出「至少有一名员工姓名含‘李’」的部门：
SELECT department FROM employees GROUP BY department HAVING GROUP_CONCAT(name) REGEXP '李';
注意点：
-
GROUP_CONCAT(name)默认用逗号连接，若姓名本身含逗号，可能干扰匹配——可加SEPARATOR ''消除分隔符：GROUP_CONCAT(name SEPARATOR '') - 如果某组数据量极大，
GROUP_CONCAT可能被截断（受group_concat_max_len系统变量限制，默认 1024），需提前检查或调大：SET SESSION group_concat_max_len = 1000000; - 正则中的特殊字符（如
.、^、$）仍需转义，和普通REGEXP规则一致
WHERE 预过滤 + HAVING 聚合筛选，才是高效组合
多数实际场景下，“分组后正则匹配”其实是伪需求。真正要的，往往是：先缩小数据范围，再按业务逻辑分组统计。
比如查「李姓员工所在部门中，平均薪资 > 8000 的部门」：
- ❌ 生硬套用
HAVING+ 正则：先全表分组，再拼接所有姓名去匹配——低效且不可扩展 - ✅ 推荐做法：
WHERE name REGEXP '^李'先筛出李姓员工，再GROUP BY department，最后HAVING AVG(salary) > 8000
这样既利用了索引（如果 name 有前缀索引），又避免了无谓的字符串拼接和正则扫描。
执行顺序决定效率：WHERE → GROUP BY → HAVING。越早用 WHERE 过滤掉无关行，后续分组和聚合的开销就越小。
REGEXP 性能差，别让它扫全表分组结果
REGEXP 本质是逐行/逐字符串回溯匹配，无法使用 B+ 树索引加速（除非走全文索引或前缀固定模式）。当它出现在 HAVING 中，意味着：MySQL 必须先完成全部分组和 GROUP_CONCAT，再对每个组的结果串跑正则——数据量稍大就明显卡顿。
替代思路更务实：
- 用
LIKE '李%'替代REGEXP '^李'（能走索引） - 把常用正则规则物化为新字段（如加
is_li_name TINYINT），配合触发器或应用层维护，查询时直接WHERE is_li_name = 1 - 真需要复杂文本分析，考虑导出到 Elasticsearch 或用 MySQL 8.0+ 的
JSON_CONTAINS+ 预处理结构
正则不是银弹；在 HAVING 里硬塞 REGEXP，往往暴露的是模型设计或查询拆解的问题，而不是语法没用对。
