必须将IP字符串转为32位整数再按数值区间归类，因字典序与数值大小不一致，直接字符串GROUP BY或BETWEEN会误判；跨库通用公式为a×16777216+b×65536+c×256+d，结果须用BIGINT存储。
直接对 IP 字符串 GROUP BY 或用 SUBSTRING_INDEX 截取段落做分组，结果不可信——字典序和数值大小不一致，BETWEEN 会漏判，CASE WHEN 硬编码难维护且无法索引。必须转为整数再按数值逻辑归并。
把 IP 字符串转成 32 位整数（跨库通用写法）
所有主流 SQL 引擎都不原生支持 CIDR 区间语义，但都支持标准字符串拆解和整型运算。手算公式 a * 16777216 + b * 65536 + c * 256 + d 是唯一可控路径。
- MySQL：用
SUBSTRING_INDEX(ip, '.', n)提取段，注意用SUBSTRING_INDEX(SUBSTRING_INDEX(ip, '.', 2), '.', -1)避免空段错误 - PostgreSQL：用
SPLIT_PART(ip, '.', n)::int，类型转换不能省 - SQL Server：用
PARSENAME(REPLACE(ip, '.', ' '), n)，但只支持 4 段，且需CONVERT(BIGINT, ...) - 结果必须存为
BIGINT或无符号类型；IPv4 最大值4294967295超出有符号INT范围
按固定网段前缀（如 /24）分组聚合
生产中极少需要动态掩码长度，硬编码比“通用函数”更稳、更易读、也避免嵌套函数导致索引失效。
- /24 网段：
INET_NTOA(INET_ATON(ip) & 0xFFFFFF00)（MySQL 专用），或跨库写法：INET_NTOA(FLOOR(ip_int / 256) * 256) - /16 网段：
INET_NTOA(FLOOR(ip_int / 65536) * 65536)（兼容 PostgreSQL/SQL Server） - 别用
WHERE ip_str LIKE '192.168.%'—— 会误吞192.168.100.1，也会漏掉192.168.0.1 - 聚合后建议用
INET_NTOA()或格式化转回可读地址，否则结果是纯数字，业务难理解
按自定义 IP 段范围（如内网、IDC、海外）做分类统计
硬写 CASE WHEN ip_int BETWEEN 167772160 AND 184549375 THEN '内网-办公区' 维护成本高，且无法走索引加速查询。
- 建一张
ip_range_map表，字段含range_name、start_ip（BIGINT）、end_ip（BIGINT） - 用
JOIN关联原始日志表：ON log.ip_int BETWEEN map.start_ip AND map.end_ip - JOIN 前确保
ip_int和start_ip/end_ip都有索引，否则大数据量下性能断崖式下跌 - 若原始表没
ip_int字段，临时分析可用 CTE 预计算：WITH ip_with_int AS (SELECT *, ... AS ip_int FROM log)
性能与线上落地的关键细节
高频按网段查的场景，千万别在每次查询里重复调用 INET_ATON() 或手算表达式——全表扫描不可避免。
- 写入侧就补全
network_24、network_16字段，并加索引；触发器或应用层计算均可 -
INET_ATON()对非法 IP（如'256.1.1.1'）返回NULL，务必前置清洗：WHERE ip REGEXP '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$' - IPv6 不适用这套整数转换逻辑；如需处理，优先用
LEFT(INET6_NTOA(ipv6_bin), 9)近似截断（仅限固定前缀场景）
