MongoDB IPv4/IPv6地理IP库ip_hex索引选型及性能优化咨询

你考虑对数值类HEX值而非字符串建B树索引的思路是合理的，而且是适配你当前业务场景的最优选择，但要先修正你当前ip_hex的存储类型问题，再谈索引配置：

• 首先立刻停止用带0x前缀的字符串存储HEX值：你当前的转换规则没有做等长补零，字符串字典序和IP实际数值大小不匹配，直接存字符串哪怕建了索引，范围查询、排序结果都会完全错误（比如字符串比较下0x10000000会被判定小于0x9000000，和实际IP数值逻辑完全相反），而且字符串索引体积远大于数值类型，内存利用率低。
• 正确的存储方式：IPv4转32位整数用BSON int32类型存储，IPv6转128位数值用16字节BinData类型存储，两种类型都可以直接用你现有的HEX转换逻辑做序列化/反序列化，不需要调整转换规则。
• 索引具体配置：
  • 不要给ip_hex建单字段索引，直接建{type: 1, ip_hex: 1}的复合B树索引：IPv4和IPv6的地址空间完全隔离，先按type过滤再匹配IP值，可以直接把索引扫描范围砍半，不管是精确IP查询、IP范围查询还是排序，性能都远好于单字段索引。
  • 绝对不要用哈希索引：哈希索引不支持范围查询和排序，完全不符合你的业务需求。
  • 如果有高频查询需要同时匹配IP、黑名单标记、生效时间，可以按需建覆盖索引，避免回表查询。

数据模型修正 #

• 拆分嵌套数组：你现在把同一个IP的所有历史地理信息、黑名单记录都存在data嵌套数组里，一旦单个IP的历史记录过多，很容易触发MongoDB单文档16MB的大小上限，而且频繁更新、插入数组元素会导致文档在磁盘上移动，产生大量存储碎片，拉低写入性能。建议把data数组拆到独立的ip_history集合，每条记录对应一个IP的一个版本信息，关联ip_hex和type字段，彻底避免大文档问题。
• 字段类型优化：blacklisted字段不要存"yes"/"no"字符串，改成布尔值true/false，减少存储空间占用，提升过滤效率。

索引优化 #

• 控制索引数量：你每天有大量增删改操作，索引越多写入开销越大，单集合索引数量尽量控制在5个以内，定期删除未被使用的冗余索引，不要给低基数字段（比如单独的blacklisted、country字段）建单字段索引，这类字段区分度极低，索引几乎不会生效。
• 所有查询必须保证命中索引：做IP查询时，传入的条件必须和存储类型一致（也就是传int32/BinData类型的数值，不要传字符串触发隐式类型转换，会直接导致索引失效）。

读写操作优化 #

• 批量写操作统一用bulkWrite接口提交，不要单条循环写入，能大幅降低网络往返开销，写入吞吐量可以提升5-10倍。
• 冷数据归档：如果超过1年的IP历史记录查询频率极低，可以按时间分集合或者分片归档，保证热数据集的体积足够小，所有热数据索引都能完全加载到WiredTiger缓存中，避免磁盘IO。
• 范围查询尽量缩小扫描范围：比如查IP段时带上type条件，不要跨IPv4/IPv6全表扫描。

部署配置优化 #

• 数百万条IP数据的规模非常小，单实例即可承载，WiredTiger缓存配置为服务器可用内存的50%-60%即可，足够装下所有热数据和索引。
• 非强一致场景下不要开majority写关注，能大幅降低写入延迟。
• 每1-2个月执行一次compact操作回收存储碎片，尤其是你有大量删改操作的场景，能避免磁盘空间无效占用，提升扫描性能。

重点提醒：优先修正ip_hex的存储类型问题，这是你当前架构里最大的隐患，不做这个调整，后续所有索引、查询优化都没有意义，甚至会查出错误的业务数据。

内容的提问来源于stack exchange，提问作者maxsand