match查询使用复合索引部分情况下查询结果为空

[benjaminlinken]

• nebula 版本：3.8.0
• 部署方式：分布式
• 安装方式：RPM
• 是否上生产环境：N
• 硬件信息
  • 磁盘（ 推荐使用 SSD）
  • CPU、内存信息
• 问题的具体描述
  如下面截图所示，我创建了一个复合索引ky_sds_0（name, device_model, total_memory, total_disk, system_version），rebuild index后进行了三次不同的查询（1、不带条件；2、带name条件；3、带name和device_model条件），发现最后一种查询方式无法获取到正确结果，请问可能是什么原因会导致这种情况？
  
  

[benjaminlinken]

发现上述查询不到数据，是由于数据存在部分属性为空，导致复合索引无法查询到结果。这个有点奇怪，是否有办法支持复合索引可以查到部分属性为空的数据？

[xjc]

@benjaminlinken

（name, device_model, total_memory, total_disk, system_version），rebuild index后进行了三次不同的查询（1、不带条件；2、带name条件；3、带name和device_model条件），发现最后一种

这个tag上没有其他索引了吧？
能否show create tag index ky_sds_0看下具体如何创建的索引？

[MuYi-方扬]

确认了下，应该是 bug。
刚才搞错了，最新的 nightly 版本还没有修复

[benjaminlinken]

针对该问题已提issue：当数据属性存在null时，match查询使用复合索引无法查询到数据 · Issue #5898 · vesoft-inc/nebula · GitHub

[benjaminlinken]

请问预期什么时候修复并合入3.8版本？

[MuYi-方扬]

收到。
还没定位，研发同学最近在搞大版本的 bug fix。估计会晚一些。

你语句注意先？

[benjaminlinken]

如下图所示，测试后发现二者性能差距较大，应该没办法直接替换

数据量

索引（注意此处建立的索引只有name和device_model，测试用的数据的这两个属性都不为null）

方式一

方式二

[MuYi-方扬]

嗯，确实是，一个做了点的类型过滤，查询出来的数据应该要少一些。
你现在对性能的要求是怎样的？我看现在都在 ms 级

[benjaminlinken]

尝试将原数据量增加10倍后，发现方式二查询延时明显上涨（变为s级），方式一没有明显变化，方式二应该是没办法在生产环境使用了。

[MuYi-方扬]

你增加的是什么原数据？我猜是因为还有其他 tag 导致的