因为里面有些反向边，你用的是 bidirect，假如你里面有下面几条边
“12” → “13”
“12” ← “14”
那么你查出来的 src都是 12，但是删除 “12” ← “14” 这条边的时候，他的src实际是 “14” 不是 “12”，所以你的反向边 相当于没有删除的。
你要同时删除正向和反向边，你可以正向查和反向查进行 union，如下
(GO FROM "12" OVER konws YIELD konws._src as src, konws._dst as dst, konws._rank as rank UNION GO FROM "12" OVER konws REVERSELY YIELD konws._dst as src, konws.src as dst, konws._rank as rank) | DELETE ……
我心思全花在测试结果上了, 忽略了这些细节, sorry 感谢回复 
这下有个问题, 应该是我解决不掉了的,
我删除100W+ 点, 里面可能有超级节点, 删除报错了, 之后查询也报错了, 是不是删除失败后数据损坏了???
之后的每次查询都会有日志报错
删除报错之后的机器监控有点异常
看下.3 这个storage是否还在，在的话，贴下这个storage的info日志，看日志，应该是挂了
go 在拿 “13” 的出边的时候就失败了，还没到后面delete，所以一个都没有删除。
你上面是删除通过go查出来的所有点，这个肯定很慢，可能整个space都快被删完
删除点的时候，会把该点的所有出入边一起删除
时间都是浪费在 GO 和 | 上，而不是 DELETE上了。
找到这100万个点并序列化花的时间远多于DELETE的时间。
嗯嗯, 这个了解, 在官网上看到了
== 的时候，这个 filter 是能推到 storage的，但是 in 的时候是没有推不下去，所以是把数据捞回来再做 filter，所以就会超时。
你好, dingding
我这有个疑问哈, 记得你上次给我说过, 默认的配置, 是删除space是不会删除对应的目录的,需要配置auto…这个参数, 我已经配置了, 然后删除了一个space, 紧接着手动执行了, SUBMIT JOB COMPACT, 完成后,对应的space目录没有删除, 这是为啥呢>?
这个目录是要重启storage后才会删除的
直接docker restart nebula_storaged0
好像不行呢 
