如何保证一个请求在 200ms 内完成

• 資深大佬 : wellsc

  具体情况具体分析

• 資深大佬 : Jooooooooo

  多个线程并发请求

  这种 io 是主要瓶颈的逻辑尽可能搞起并发

• 資深大佬 : isukkaw

  50ms 这个量级其实很微妙。

  该缓存缓存，该并发并发。

• 資深大佬 : hronro

  5 个 SQL 能否并行查询，还是之间有依赖关系？是否用了 ORM 之类的东西可能拖慢查询速度？

• 資深大佬 : jiahonzheng

  1. 看业务，如果可以缓存，那就上缓存

• 資深大佬 : js8510

  sharding. cache. 看看设计能不能提高并发 单一服务能不能拆分然后 fan out 等等等。。 你这个问题太宽泛了。

• 資深大佬 : nvkou

  说实话 200 毫秒应该要被考虑到网络波动的量级。要保证 200 不只是数据库问题

• 資深大佬 : fengchang

  查询一张表单独根据 id 条件查询大概要 0.04~0.05 秒

  —-

  根据 id 查询 50ms 是有点慢了，但是不知道你的数据库具体情况

  ID 是主键吗？
  硬盘上 SSD 了吗？
  列是不是太多了，所有列都是必要的吗？

• 資深大佬 : opengps

  提高硬盘速度
  优化 sql
  并发提升其实不一定大

• 資深大佬 : kaiki

  不知道实际情况不好给建议，不过能优化的大概也就是查询这块了，提前准备好缓存数据把查询省掉的话，能快很多。

• 資深大佬 : 594duck

  我们问题要一个一个的讲
  首先 200ms 这个死线是怎么来的，你监控自己的 API 响应的时候，要区分出 request 和 proxy 的流量，然后要把流量分成 97%，95%,80%,50%，20%.只要 request r95%是小于 200ms 就 OK

  第二，关于 SQL 语句，我们也要具体问题具体看，首先，你的 SQL 表有多少行，什么配置，查询一次 40ms 是为什么，他是不是必须这么慢，比如 OLAP 的就这么慢是说的过去的大不了改为异步。但是如果是 OLTP 的数据库，理论上每一个请求必须在 10ms 内完成。具体你要说一下你的架构，数据库配置，数据库最慢的表是什么表，是不是有 cache，有没有读写分离。

• 資深大佬 : 594duck

  数据库最慢的表有多少行，存的字段是什么样的，一次读取的量大概有多大。

  你查一次 40ms，那要扫描多少行，遍历 多少行

• 資深大佬 : 594duck

  不是很认同上手叫你上什么 SSD，加 IO 硬盘的，属于不懂 RCA 分析法的选手

• 資深大佬 : ericls

  不结合业务讨论意义不大 如果你要不惜一切代价的话 拆分成多个请求 总体速度会降低 但是单个请求会快 你愿意吗？ 还有个好处 看上去的并发性能会好一些

• 資深大佬 : wangritian

  主键查询几十毫秒真的慢了，先在服务器 ping 一下数据库或是用命令行查询看看时间，然后看看数据库的负载是不是太高，另外你做长连接了吗

• 資深大佬 : la2la

  网络延迟，数据库 IO，业务逻辑这个三个方面看看哪方面是瓶颈，在针对性的优化。不过一般我碰到的大部分都是数据库 SQL 执行问题

• 資深大佬 : binbinyouliiii

  200 毫秒对于前端感知来说还好，比如你用阿里云的控制面板，超过 200ms 是经常的事情

• 資深大佬 : KarlChen2015

  主键查询 1ms 足矣
  我这是 200 万记录的表

• 資深大佬 : zppass

  一般来说几百毫秒还能接受，但是你这 5 个查询，首先要考虑有些不怎么会变的，是不是可以考虑用 redis 存起来，另外优化 SQL，不要出现循环里面套 SQL 的情况。还有就是主键查询，其实蛮快的，考虑一下上老哥们的说法排查。
  至于并发，实际上你这个请求结果，用户不需要即时感应的话，其实异步多线程就可以了。比如说生成一个人工订单不能马上反馈那种，没必要把东西都搞完再返回。

• 資深大佬 : Yano

  如果数据库不经常变动，感觉可以缓存起来，不过根据主键 id 查询的应该很快。同时 sql 只查询必要字段，不用把所有列都返回