MySQL中应使用INET_ATON()和INET_NTOA()处理IPv4地址，二者支持标准网络字节序的双向转换，配合INT UNSIGNED字段存储可优化索引与查询；需校验IP合法性，避免非法输入返回0导致数据异常。
MySQL里用INET_ATON()和INET_NTOA()就够了，别自己写函数
MySQL原生就支持IPv4地址与整型的双向转换，INET_ATON()把点分十进制IP转成无符号整型（如'192.168.1.1' → 3232235777），INET_NTOA()反向转换。这两个函数底层用的是标准网络字节序（大端），结果可直接用于范围查询、索引优化或排序。自己写UDF不仅没必要，还容易出错——比如忽略UNSIGNED INTEGER溢出问题，或误用小端序。
为什么INET_ATON()返回值是BIGINT但实际存INT UNSIGNED更合理
INET_ATON()返回类型是BIGINT，但IPv4地址最大值255.255.255.255对应整数4294967295，刚好卡在INT UNSIGNED上限（2^32 - 1）。如果字段定义成BIGINT，浪费存储且索引效率略低；定义成INT（有符号）则会把大于2147483647的IP（如128.0.0.1以上）转成负数，导致查询错乱。
- 建表时用
INT UNSIGNED存储转换结果，例如：CREATE TABLE logs (ip INT UNSIGNED, ...);
- 插入时显式转换：
INSERT INTO logs (ip) VALUES (INET_ATON('10.0.0.1')); - 查询时用
INET_NTOA(ip)还原，但注意：如果ip列是INT（非unsigned），INET_NTOA()对负数返回NULL
INET_ATON()遇到非法IP会静默返回0，必须提前校验
这是最容易踩的坑：INET_ATON('999.999.999.999')或INET_ATON('192.168.1')都返回0，而不是报错。如果业务依赖IP字段做唯一性约束或关联查询，0可能被当成合法值插入，后续查不到数据却找不到原因。
- 插入前加校验逻辑，例如用正则：
WHERE ip_str REGEXP '^([0-9]{1,3}\.){3}[0-9]{1,3}$' - 再配合数值范围检查：
AND CAST(SUBSTRING_INDEX(ip_str, '.', 1) AS UNSIGNED) BETWEEN 0 AND 255
（需对每一段重复） - 更稳妥的做法是在应用层校验，MySQL里用触发器成本高、可读性差
IPv6不支持，别试图用INET6_ATON()兼容IPv4
INET6_ATON()和INET6_NTOA()专为IPv6设计，返回的是BINARY(16)，不能和IPv4整型互换。有人试过把INET_ATON()结果塞进INET6_NTOA()，结果是乱码或NULL。如果系统要同时支持IPv4/IPv6，得分开字段存：一个INT UNSIGNED存IPv4整型，一个VARBINARY(16)存IPv6二进制，查询时用IS_IPV4()/IS_IPV6()判断类型再走对应逻辑。
真正麻烦的不是转换本身，而是校验缺失和类型定义错误——这两个点一旦漏掉，数据写进去就不可逆，查起来像幽灵bug。
