HAVING不能直接删除数据，必须通过子查询或CTE先筛选异常分组，再关联删除；例如用GROUP BY+HAVING找出单日登录超5次的user_id和日期，再用IN或EXISTS删除对应全部记录。
HAVING 不能直接删除数据，必须配合子查询或CTE
SQL标准中 HAVING 只能用于分组后的筛选，它本身不是DML语句，**不能直接跟 DELETE**。试图写 DELETE ... HAVING ... 会报语法错误（如 MySQL 的 ERROR 1064，PostgreSQL 的 syntax error at or near "HAVING"）。真正可行的路径是：先用 HAVING 找出异常分组，再通过子查询或 CTE 获取具体行的主键/唯一标识，最后执行删除。
用子查询定位并删除重复超限的用户记录
典型场景：删除「同一 user_id 在单日登录次数 > 5」的所有记录（不是只删一条，而是删掉这些异常登录的全部行）。
- 先在子查询中用
GROUP BY user_id, DATE(login_time)+HAVING COUNT(*) > 5找出异常分组 - 外层
DELETE通过IN或EXISTS关联原始表，匹配这些分组下的完整记录 - MySQL 示例（注意：MySQL 8.0+ 支持直接
DELETE ... JOIN，但老版本需子查询）：
DELETE FROM login_logs WHERE (user_id, DATE(login_time)) IN ( SELECT user_id, DATE(login_time) FROM login_logs GROUP BY user_id, DATE(login_time) HAVING COUNT(*) > 5 );
⚠️ 注意：MySQL 5.7 默认禁止子查询引用被删表（ERROR 1093），此时必须套一层派生表：
DELETE FROM login_logs
WHERE (user_id, DATE(login_time)) IN (
SELECT * FROM (
SELECT user_id, DATE(login_time)
FROM login_logs
GROUP BY user_id, DATE(login_time)
HAVING COUNT(*) > 5
) AS tmp
);用 CTE + 窗口函数更安全地处理复杂条件
当异常逻辑涉及「每组内排序后取 top N」或「累计值越界」时，HAVING 不够用，改用窗口函数配合 CTE 更可控。例如：删除每个 user_id 下最近 3 条之外的所有历史记录（保留最新3条，其余删掉）。
-
HAVING无法表达“每组内按时间倒序取前3”，但ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC)可以 - CTE 先算出行号，主
DELETE再过滤rn > 3 - PostgreSQL / SQL Server / MySQL 8.0+ 均支持：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY login_time DESC
) AS rn
FROM login_logs
)
DELETE FROM login_logs
WHERE id IN (SELECT id FROM ranked WHERE rn > 3);⚠️ 切记：CTE 中的 id 必须是唯一可定位字段（如主键），否则可能误删；且部分数据库（如 SQLite）不支持 CTE 用于 DELETE 的 FROM 子句，需改用子查询。
删除前务必加 WHERE 条件限制范围，避免全表扫描锁表
真实环境中，HAVING 筛选的往往是小比例异常数据，但关联删除时若没加时间范围或状态过滤，可能触发全表扫描，导致锁表、慢查询甚至 OOM。
- 永远在子查询或 CTE 的原始
FROM表上加前置过滤，比如WHERE login_time >= '2024-01-01' - 避免对无索引字段（如
DATE(login_time)）做分组——这会强制全表计算，应确保login_time有索引，且尽量用范围查询代替函数包裹 - 大表操作前先用
SELECT COUNT(*)验证子查询结果集大小，例如：
SELECT COUNT(*) FROM login_logs WHERE (user_id, DATE(login_time)) IN ( SELECT user_id, DATE(login_time) FROM login_logs WHERE login_time >= '2024-01-01' GROUP BY user_id, DATE(login_time) HAVING COUNT(*) > 5 );
真正执行删除前，没人会替你检查 login_time 字段是否被函数破坏了索引有效性，也没人知道那个 IN 子查询到底返回了几万行。
