必须将IP字符串转为32位无符号整数（如a×16777216+b×65536+c×256+d）并存为BIGINT，再按FLOOR(ip_int/256)×256等对齐网段分组，避免字符串模糊匹配导致的逻辑错误与性能问题。
必须先把 IP 字符串转成整数，否则分组全错
直接对 ip 字段用 GROUP BY 或 LIKE '192.168.%'，结果不可信——“192.168.10.1”字典序大于“192.168.2.1”，但数值更小；BETWEEN '192.168.1.1' AND '192.168.10.255' 会漏掉中间大量地址。所有主流 SQL 引擎（MySQL、PostgreSQL、SQL Server）都不原生支持 CIDR 区间语义（PostgreSQL 的 inet 类型除外），必须手动转为 32 位无符号整数。
跨库通用公式是：a * 16777216 + b * 65536 + c * 256 + d，其中 a.b.c.d 是四段数字。结果必须存为 BIGINT 或无符号类型，因为最大值 4294967295 超出有符号 INT 范围。
- MySQL：用
SUBSTRING_INDEX(ip, '.', 1)提取第一段，注意第 n 段要套两层SUBSTRING_INDEX防空段 - PostgreSQL：用
SPLIT_PART(ip, '.', n)::int，类型转换不能省 - SQL Server：用
PARSENAME(REPLACE(ip, '.', ' '), n)，只支持 4 段，且需CONVERT(BIGINT, ...)
按固定网段前缀（如 /24）分组，别用字符串模糊匹配
查 “属于哪个 /24 网段”，本质是把 IP 整数向下对齐到 256 的倍数：FLOOR(ip_int / 256) * 256。这个值就是该网段起始地址的整数形式，再用 INET_NTOA()（MySQL）或自定义格式化函数转回 192.168.1.x 这类可读形式。
错误做法：WHERE ip_str LIKE '192.168.1.%' —— 会吞掉 192.168.100.1，也会漏掉 192.168.1.0；SUBSTRING_INDEX(ip_str, '.', 3) 分组在跨段时失效（比如 10.1.100.1 和 10.1.10.1 被分到不同组）。
- /24 网段分组表达式：
FLOOR(ip_int / 256) * 256 - /16 网段分组表达式：
FLOOR(ip_int / 65536) * 65536 - 聚合后建议立刻转回字符串，否则输出全是数字，业务方看不懂
按自定义 IP 段（如内网、IDC）分类，用 JOIN 替代硬编码 CASE WHEN
硬写 CASE WHEN ip_int BETWEEN 167772160 AND 184549375 THEN '内网-办公区' 看似简单，但维护成本高、无法走索引、改范围就得改 SQL。正确做法是建一张维度表：
一款AI办公效率工具，主要用于Your ultimate AI-powered notetaking and learning companion.，适合需要提升相关任务效率的用户。
CREATE TABLE ip_range_map ( range_name VARCHAR(50), start_ip BIGINT UNSIGNED, end_ip BIGINT UNSIGNED );
然后关联日志表：ON log.ip_int BETWEEN map.start_ip AND map.end_ip。关键前提是 log.ip_int、map.start_ip、map.end_ip 都要有索引，否则大数据量下性能断崖下跌。
- 原始表没
ip_int字段？临时分析可用 CTE：WITH ip_with_int AS (SELECT *, ... AS ip_int FROM log) - JOIN 前务必检查执行计划，确认是否命中索引；否则先补字段再建索引
- 避免在 WHERE 中写
ip_int IN (SELECT ...)，子查询结果集大时极慢
线上高频查询必须预计算字段，别在每次 SELECT 里手算 IP 整数
如果每天都有大量查询按网段统计访问量，千万别在每个 SELECT 里重复调用 SUBSTRING_INDEX 或手算表达式——全表扫描不可避免，CPU 和 IO 压力陡增。生产环境应写入侧补全 network_24、network_16 字段，并加索引。
实现方式有两种：INSERT/UPDATE 触发器自动填充，或应用层在写入前计算好。后者更可控，避免数据库触发器逻辑膨胀难维护。
- 预计算字段名建议带语义，如
ip_network_24_int、ip_network_24_str - 索引优先建在
ip_network_24_int上，比在原始ip_str上建前缀索引更高效 - 历史数据迁移可用批量 UPDATE，但注意锁表时间和事务大小
最易被忽略的一点：IP 转整数和网段对齐这两个步骤，看似简单，但一旦漏掉类型声明（如没转 BIGINT）、没建索引、或在查询中重复计算，就会让本该毫秒级的聚合变成分钟级卡顿。
