不能直接用于cidr匹配，但它是基础：inet_aton()将ipv4转为int unsigned整数以支持位运算和范围比较，ipv6必须用inet6_aton()返回binary(16)，而字符串like匹配会漏判边界且不支持任意掩码长度。
MySQL 8.0+ 的 INET_ATON() 和 INET6_ATON() 能否直接用于 CIDR 匹配？
不能直接用，但它是基础。CIDR 匹配本质是「判断一个 IPv4 地址是否落在某个网络前缀范围内」，需要把 CIDR（如 192.168.1.0/24）拆解为起始 IP 和结束 IP，再做数值范围比较。INET_ATON() 把点分十进制转为无符号整数（INT UNSIGNED），才能做位运算和比较；IPv6 则必须用 INET6_ATON()（返回 BINARY(16)），不能用 INET_ATON()。
常见错误是直接对字符串做 LIKE 或 SUBSTRING 比较，比如 ip LIKE '192.168.1.%' —— 这漏掉 192.168.1.255 以外的边界情况，且无法处理 /27、/30 等非八位掩码。
- IPv4 掩码长度
/n对应的网络掩码整数 =(0xffffffff - 起始地址 =
INET_ATON('192.168.1.100') & mask - 结束地址 = 起始地址 | (~mask & 0xffffffff)
- 匹配条件：
INET_ATON(ip_col) BETWEEN start_ip AND end_ip
如何写一个可复用的 CIDR 匹配表达式（IPv4）？
不依赖函数定义，纯 SQL 表达式更可控，也避免 MySQL 函数权限或版本限制。假设字段 client_ip 是 VARCHAR，CIDR 值来自参数或另一张表：
SELECT *
FROM access_log
WHERE INET_ATON(client_ip) >= (
INET_ATON(SUBSTRING_INDEX('192.168.1.0/24', '/', 1))
& (0xffffffff <p>这段太长，实际建议封装成子查询或临时变量（MySQL 8.0+ 支持 <code>WITH</code>）；更推荐预计算好 <code>network_start</code> 和 <code>network_end</code> 存入配置表，避免每次解析 CIDR 字符串。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2334" title="MySQL"><img
src="https://img.php.cn/upload/skill/000/000/081/178900927846657.jpg" alt="MySQL" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="overflowclass">MySQL</a>
<p class="overflowclass">编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。</p>
</div>
<a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
-
SUBSTRING_INDEX()提取 CIDR 中的 IP 和掩码位数，注意它返回字符串，需显式转类型 - 位移运算在 MySQL 中对负数行为未定义，务必用
& 0xffffffff截断高位 -
INET_ATON()遇到非法 IP 返回NULL，会导致整个条件为UNKNOWN，查不到数据 —— 生产环境必须加IS NOT NULL校验
为什么 INSTR() 或正则无法可靠替代 CIDR 匹配？
因为 CIDR 不是字符串前缀问题。例如 10.0.0.0/12 覆盖从 10.0.0.0 到 10.15.255.255，而 10.0.0.0/13 只覆盖到 10.7.255.255。用 LEFT(client_ip, 4) = '10.0' 或正则 ^10\.0\. 会误判或漏判。
- 正则
REGEXP '^10\.(0|1|2|3|4|5)\.'写起来极难维护，且无法索引，性能差 -
INSTR()完全无视网络拓扑，INSTR('10.16.0.1', '10.0.') > 0会错误认为它属于10.0.0.0/12 - IPv6 更不可行：
INET6_ATON()返回二进制，无法用字符串函数安全切分
IPv6 CIDR 匹配必须用 INET6_ATON() + 二进制操作
MySQL 对 IPv6 的 CIDR 支持有限，INET6_ATON() 返回 BINARY(16)，不能直接位运算。正确做法是用 HEX() 转成字符串，按字节逐段计算掩码，或借助应用层预处理。简单但安全的做法是：只在应用层解析 CIDR，生成起始和结束地址的 BINARY(16) 值，再用 BETWEEN 比较：
WHERE INET6_ATON(client_ipv6) BETWEEN
UNHEX('20010db8000000000000000000000000')
AND
UNHEX('20010db80000ffff0000000000000000');
硬编码十六进制字符串虽冗长，但稳定、可索引、无运行时解析开销。MySQL 8.0.29+ 提供了 INET6_CIDR_SUBNET() 和 INET6_CIDR_MASK()，但它们只返回掩码本身，仍需手动组合逻辑，且文档明确标注「实验性」，生产环境慎用。
CIDR 解析本身有边界细节：/0、/32、::/0、::1/128 都要单独测试；IPv4 映射的 IPv6 地址（如 ::ffff:192.168.1.1）需额外判断是否启用兼容模式。这些不是函数能自动兜底的。
