用SUBSTRING_INDEX(ip,'.',3)截取IPv4前3段实现/24网段分组，WHERE过滤必须在GROUP BY前，非分组字段需聚合处理，异常判定应结合动态分位数而非固定阈值。
GROUP BY 怎么截取 IP 段做分组？
直接 GROUP BY ip 只能统计单个 IP，但异常分析通常关注网段（比如 /24 或 /16），得先截断。MySQL 用 SUBSTRING_INDEX 最稳妥，PostgreSQL 用 SPLIT_PART 或正则，SQL Server 得靠 LEFT + CHARINDEX 配合。别用字符串拼接或模糊匹配——性能差还容易错位。
常见写法示例（MySQL）：
SELECT SUBSTRING_INDEX(ip, '.', 3) AS ip_segment, COUNT(*) AS cnt FROM access_log WHERE status >= 400 GROUP BY SUBSTRING_INDEX(ip, '.', 3) ORDER BY cnt DESC LIMIT 10;
注意：这里 SUBSTRING_INDEX(ip, '.', 3) 提取前三段（如 192.168.5），不是“前 3 个字符”；如果 IP 是 IPv6，这套逻辑完全失效，得换正则或专用函数。
WHERE 条件放 GROUP BY 前还是后？
必须放在 GROUP BY 前，也就是写在 WHERE 子句里。如果把过滤逻辑挪到 HAVING，会先全量分组再筛，白白消耗资源。尤其日志表动辄上亿行，HAVING COUNT(*) > 100 这种写法会让数据库算完所有网段才扔掉低频的。
要筛异常访问，优先在 WHERE 中明确条件：
-
status NOT IN (200, 301, 302)—— 排除正常响应 -
user_agent LIKE '%sqlmap%' OR user_agent LIKE '%nmap%'—— 结合 UA 特征 request_time —— 限定时间范围，避免全表扫描
统计结果怎么判断“异常频次”？
没有绝对阈值，得结合基线。比如同一网段 1 小时内请求超 500 次，可能正常（CDN 回源）；但如果是 5 分钟内 200 次 404，就值得报警。别硬写 HAVING COUNT(*) > 100 了事。
更实用的做法是加窗口函数算动态分位数（如果数据库支持）：
SELECT ip_segment, cnt, PERCENT_RANK() OVER (ORDER BY cnt) AS rank_pct FROM ( SELECT SUBSTRING_INDEX(ip, '.', 3) AS ip_segment, COUNT(*) AS cnt FROM access_log WHERE status >= 400 AND request_time > NOW() - INTERVAL 1 HOUR GROUP BY SUBSTRING_INDEX(ip, '.', 3) ) t WHERE rank_pct > 0.95;
这个查出来的是当前小时里访问频次排前 5% 的网段——比固定数字更抗干扰。
为什么 GROUP BY 后 SELECT 其他字段会报错？
这是 SQL 标准行为，不是 bug。当你 GROUP BY ip_segment，数据库只保证该字段确定，其他字段（比如 user_agent、url）每组有多个值，它不知道该返回哪一个。MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY，直接报错；旧版本虽不报错，但返回的非分组字段值是随机的，结果不可信。
真要带出典型请求，得用聚合函数包裹：
-
MAX(url)或ANY_VALUE(url)（MySQL）——仅作参考，不保证代表性 - 想看具体某条高危请求，得先子查询出 top 网段，再
JOIN原表捞样本 - 别在同一个 SELECT 里混用
GROUP BY和未聚合的明细字段
IP 段聚合本身不复杂，难的是定义“异常”——它依赖时间窗口、业务特征、历史基线，而不是 GROUP BY 写得有多漂亮。
