首页
学习
活动
专区
圈层
工具
发布
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    GraphQL API查询性能暴跌

    跑了个简单的find查询,单条查询很快,排除MongoDB本身问题。...检查查询逻辑:GraphQL的resolver直接把所有订单查出来,数据量大时会不会是N+1问题?我检查了schema,orders查询不涉及嵌套,排除N+1问题。...怀疑索引:我跑explain()看查询计划,发现userId字段没建索引,导致全表扫描。赶紧加索引试试。进一步优化:加索引后性能好了一些,响应降到1秒,但还是慢。...解决方案我决定从两方面优化:加索引减少数据库查询时间,分页限制返回数据量。...避坑总结索引是救命稻草:MongoDB查询性能差,先检查索引,userId和排序字段要建复合索引。分页是标配:GraphQL查询数据量大时,必须用limit和offset分页,减少序列化开销。

    25210

    # 在线业务迁移查询服务到ElasticSearch

    随着业务数量的增大,部分批量查询会导致数据库的慢查询(已经增加了索引),比如模糊搜索等,所以准备迁移到ElasticSearch 要求 平滑迁移,不影响用户使用 为了降低风险,接口会逐个切换 减少测试工作量...方案 数据同步方案 使用Flink SQL CDC迁移MYSQL数据到ES 业务升级方案 平行请求再对比: 这样的方式可以减少测试工作量,不需要测试肉眼对比查询结果是否一致 设置不同的工作模式,而且支持动态切换...,哪个先返回则使用其结果 RETURN_SQL_WITH_CHECK: 使用MYSQL的结果,但是会对比ES,如果有不一致则需要输出到日志,方便后续分析(可以异步ES结果对比) 工作模式可以精确到一个查询接口

    1.5K20
    领券