HAVING子句必须跟在GROUP BY之后使用，否则MySQL报错；CI框架不会自动补GROUP BY，需显式调用group_by()；HAVING不能直接引用SELECT别名（CI 3.x），推荐用原始表达式；CI 4.x的having()数组语法易误用，建议用三参数形式；封装时需重置查询避免条件污染。
MySQL中HAVING子句必须跟在GROUP BY之后使用
直接在没有GROUP BY的查询里写HAVING，MySQL会报错ERROR 1054 (42S22): Unknown column ... in 'having clause'——因为HAVING只作用于分组后的临时结果集，不是过滤原始行。CI（CodeIgniter）的Query Builder不会帮你自动补GROUP BY，哪怕你只调用了$this->db->having()。
实操建议：
- 先确认业务是否真需要聚合：比如“找出订单总额超5000的用户”，才用
GROUP BY user_id+HAVING SUM(amount) > 5000 - CI中必须显式调用
$this->db->group_by('user_id')，不能省略 - 若误把
WHERE逻辑写进HAVING（比如过滤单条记录的状态），性能会变差——数据库得先聚合再过滤，而不是提前剪枝
CI 3.x中having()方法不支持表达式别名引用
比如你写了$this->db->select('SUM(price) as total')，然后想用$this->db->having('total > 100')——CI 3.x会原样拼SQL，而MySQL不允许在HAVING里直接用SELECT中的别名（除非是8.0+且启用了sql_mode=ONLY_FULL_GROUP_BY放宽限制）。
实操建议：
- 一律用原始字段或函数表达式：改写为
$this->db->having('SUM(price) > 100') - 避免嵌套函数：如
HAVING ROUND(AVG(score)) > 85在CI中容易因括号转义出错，建议移到SELECT里计算后用字段名过滤 - 如果必须用别名，改用
$this->db->query()手写SQL，CI的Query Builder对此支持有限
CI 4.x中having()可接受数组但需注意键值语义
CI 4支持$builder->having(['SUM(qty) >' => 100])，但这里的键不是字段名，而是完整条件左半部分；值也不是阈值，而是右半部分。容易误写成['total >' => 100]导致SQL语法错误。
实操建议：
- 推荐用三参数形式：
$builder->having('SUM(qty)', 100, '>')，语义清晰且防注入 - 数组方式仅适用于简单等值判断，如
$builder->having(['status' => 'active'])，此时才是字段=值 - 涉及函数、运算符或NULL判断时，别用数组——
$builder->having('price IS NULL')比['price' => null]可靠得多
自定义类封装HAVING逻辑时要隔离SQL上下文
如果你写了一个ReportFilter类，里面封装了addRevenueThreshold()方法并调用$this->db->having()，要注意：CI的DB实例是全局共享的。如果多个地方并发调用这个类，可能互相污染HAVING条件。
实操建议：
- 每次构建查询前，用
$this->db->reset_query()清空条件（CI 3.x）或$builder->resetQuery()（CI 4.x） - 不要在类属性里长期持有
$this->db引用，改用方法参数传入Builder实例 - 聚合条件最好和
SELECT/GROUP BY一起组织，例如封装成buildRevenueSummaryQuery($min_total)，而不是零散调用having()
复杂聚合查询里，HAVING的边界感最容易被忽略：它既不是WHERE的替代品，也不能脱离GROUP BY独立存在。写之前先手写一遍原生SQL，能避开大半坑。
