MySQL 8.0.19+ 推荐用 VARBINARY(16) 配合 INET6_ATON()/INET6_NTOA()，但需业务层统一处理双栈逻辑；否则 VARCHAR(39) 更省心。
IP字段该用 VARBINARY(16) 还是 INET6_ADDR 函数族？
直接说结论：mysql 8.0.19+ 推荐用 varbinary(16) 配合 inet6_aton()/inet6_ntoa()，但前提是业务层能统一处理 ipv4/ipv6 双栈逻辑；否则，varchar(39) 更省心，尤其当查询里频繁做字符串匹配或调试日志多时。
原因很简单：VARBINARY(16) 存的是二进制值，节省空间（IPv6 固定 16 字节）、支持索引高效范围扫描，但所有读写都必须经过转换函数，漏一个就存成乱码或查不到。
-
INET6_ATON('127.0.0.1')返回0x0000000000000000000000007F000001（16 字节），而INET6_ATON('::1')返回0x00000000000000000000000000000001 - 如果插入时忘了调
INET6_ATON()，比如直接INSERT INTO t(ip) VALUES ('192.168.1.1')，那存进去的就是字符串字节流，长度可能 10+，和预期的 16 字节二进制完全对不上 - MySQL 5.6–8.0.18 没有原生 IPv6 支持函数，
INET_ATON()只认 IPv4，传 IPv6 会返回NULL，极易静默失败
建表时 VARBINARY(16) 字段必须配 NOT NULL 和默认值吗？
必须设 NOT NULL，但默认值慎设。空 IP 在语义上通常不是“未知”，而是“未采集”或“无效”，用 NULL 更准确；强行设默认值如 0x00000000000000000000000000000000 会污染数据，后续无法区分是真地址还是占位符。
- 建表语句示例：
ip_addr VARBINARY(16) NOT NULL，别加DEFAULT - 应用层插入前务必校验：先用
filter_var($ip, FILTER_VALIDATE_IP)（PHP）或ipaddress.ip_address()（Python）判断合法性，再调数据库函数转换 - 如果业务允许空值，就明确用
ip_addr VARBINARY(16) NULL，别为了“不为空”硬塞0x00...
WHERE ip_addr = INET6_ATON(?) 为什么有时查不到？
最常见原因是参数没走预处理，或者客户端把问号当字符串字面量传了进去。比如 PHP 中写成 $stmt->execute(['192.168.1.1']) 却没在 SQL 里调 INET6_ATON()，等于拿字符串和二进制比，必然失败。
- 正确写法（PDO）：
SELECT * FROM logs WHERE ip_addr = INET6_ATON(?)，然后$stmt->execute(['192.168.1.1']) - 错误写法：
SELECT * FROM logs WHERE ip_addr = ?+$stmt->execute([inet_pton('192.168.1.1')])—— PHP 的inet_pton返回的是二进制字符串，长度可能不对（IPv4 是 4 字节，但VARBINARY(16)期待 16 字节补零后的结果） - 调试技巧：手动执行
SELECT HEX(INET6_ATON('192.168.1.1'))，看是不是00000000000000000000FFFFC0A80101（注意前面补零逻辑）
从 VARCHAR 迁移到 VARBINARY(16) 容易卡在哪？
迁移本身不难，难在存量数据清洗和应用层适配。特别是老系统里 IP 字段可能混着代理头、端口号、甚至逗号分隔的多个地址，比如 '192.168.1.1:8080' 或 '10.0.0.1, 172.16.0.2'，直接套 INET6_ATON() 全报错。
- 先跑一遍清洗 SQL：
UPDATE t SET ip_addr = INET6_ATON(SUBSTRING_INDEX(ip_str, ',', 1)) WHERE ip_str REGEXP '^[0-9.:a-fA-F]+$'，只处理格式干净的 - 应用层所有 ORM 查询（如 Laravel 的
where('ip_addr', $ip)）必须改成whereRaw('ip_addr = INET6_ATON(?)', [$ip]) - 备份不能只靠
mysqldump，因为VARBINARY导出是十六进制字符串，恢复时若没加--hex-blob会变成乱码
真正麻烦的从来不是字段类型，而是 IP 值在 HTTP Header、Nginx 日志、SDK 上报里是否被标准化过——这些地方没对齐，数据库改得再漂亮也没用。
