inet_aton() 返回 0 是因输入非标准ipv4格式，如含空格、前导零、ipv6或空字符串；inet_ntoa() 返回 null 是因输入超范围、为负数或null；存储ip优先选int unsigned。
为什么 INET_ATON() 返回 0？常见误用场景
INET_ATON() 不是万能解析器，它只接受标准 IPv4 点分十进制格式（如 "192.168.1.1"），遇到任意非数字、多余空格、前导零（如 "192.168.01.1"）、IPv6 或空字符串都会静默返回 0 —— 而 0 在 MySQL 中也是合法的整数值，容易被当成“转换成功”。
- 字符串前后有空格？先用
TRIM()清理：INET_ATON(TRIM(ip_str)) - 前导零问题？MySQL 5.7+ 会拒绝
"010.0.0.1"（视为非法），但旧版本可能转成错误值；建议在写入前校验或标准化 - 混合了 IPv6？
INET_ATON()完全不支持，会返回0；别指望它兜底
INET_NTOA() 返回 NULL 的真实原因
INET_NTOA() 接收一个无符号整数（INT UNSIGNED），但它对输入极其敏感：只要传入值超过 4294967295（即 2^32 - 1），或为负数、NULL，就直接返回 NULL，不会报错。
- 存储字段类型必须是
INT UNSIGNED，用INT SIGNED存INET_ATON()结果会导致高位截断（比如192.168.255.255→3232235775，若用有符号 INT 可能存成负数） - 从其他系统导入整数 IP 时，确认来源是否保证在
[0, 4294967295]范围内 - 直接写 SQL 测试时别手误：例如
INET_NTOA(0x100000000)（超限）或INET_NTOA(-1)都返回NULL
IPv4 存储选 VARCHAR(15) 还是 INT UNSIGNED？性能与查询代价对比
存字符串看着省事，但真实代价藏在查询里：
- 索引效率：字符串比较按字典序逐字符比，
INT UNSIGNED是单次整数比较，范围查询（如查某网段）快一个数量级 - 网段匹配难：想查
"192.168.1.x"，字符串得用LIKE "192.168.1.%"（无法走索引前缀），而整数可算：ip_int BETWEEN INET_ATON("192.168.1.0") AND INET_ATON("192.168.1.255") - 额外存储开销小到忽略：4 字节 vs 最长 15 字节，但索引大小和内存占用差异明显
所以除非你从不按 IP 做条件查询、只做展示，否则优先存整数。
MySQL 8.0+ 用户注意：INET6_ATON() 和 INET6_NTOA() 不能替代老函数
这两个新函数支持 IPv6，但行为和兼容性有硬限制：
-
INET6_ATON()对 IPv4 输入仍返回二进制（16 字节），不是等价的 4 字节整数；也就是说，它和INET_ATON()输出类型不同，不能混用 - 查询时若字段存的是
INET_ATON()结果（4 字节整数），不能用INET6_NTOA()反解，会出乱码 - IPv4 映射地址（如
::ffff:192.168.1.1）需显式处理，INET6_ATON()不自动降级
真要统一支持双栈，建议单独建字段存 IPv6 二进制，IPv4 继续走老函数，别强行用新函数覆盖旧逻辑。
IP 地址转换看着简单，但 INET_ATON() 和 INET_NTOA() 的边界行为、类型隐式转换、版本差异，随便踩一个就让查询结果“看似正常实则错漏”。最稳妥的做法是：入库前校验格式，存整数，查网段用位运算或范围计算，别依赖函数兜底。
