常有小伙伴说，有时会觉得文档看懂了，但实战依然头大；有个复杂的查询需求，不知如何优雅地落地，翻遍全网也没有参考资料。
现在，“查询命题作文”来啦！NebulaGraph 核心研发 @jievince 负责埋头码字、调试、写干货，而你们，来决定他写什么～
规则很简单：
- 回帖留下你最想看到的 “NebulaGraph 查询”相关话题。
- @jievince 将选择呼声最高、或最具普适性的命题，产出一篇包含场景、思路、代码、优化和总结的完整技术文章。
这一次，文章的命题权完全交给社区。但为确保我们产出的内容能最大限度地帮助到更多人，我们需要你的命题 “不止于解决一个具体问题，更能启发一类场景” 。
我们需要什么样的命题？
请在提出命题前，用以下三点来衡量一下，这将决定它最终能否成为一篇经典的指南文章：
- 问题具有通用场景，而非偶发个案
好的命题： “如何优雅地处理图数据中‘超级节点’导致的查询性能问题？”
不合适的命题： “帮我优化一下我们公司A业务中这个MATCH语句。”（此类具体业务问题请单独发帖，我们会直接解答。）
- 答案能归纳为模式、方法论或最佳实践
- 好的命题： “在实现‘好友推荐’或‘商品推荐’时，有哪些基于图的查询模式可以参考？”
- 不合适的命题： “帮我写一个查询，找出用户ID为123的所有二度好友。”
- 挑战指向核心功能或常见设计抉择
- 好的命题： “使用子查询（如
WITH）进行多步计算时，有哪些必须注意的性能陷阱和优化手段？”
举个栗子
：
“数据查询慢，常见的查询调优方案”
“从0到1，手把手教你写 nGQL”
别犹豫，在评论区尽情“点菜”
本帖也将作为查询灵感库，如果你想为社区贡献文章，欢迎从中寻找灵感～
记得给你想看的话题点赞哦～！ 让研发小哥看见群众的呼声 (•̀ᴗ• ) ̑̑.