是偶现还是常态？
偶现的话，看是否网络抖动导致 B 的回包超时； A 节点负载是否过高；
常态的话，分析 A 模块逻辑，除了简单 rpc 调用，是否还做了其他耗时逻辑，导致你统计本身就不对？框架本身是否有自动换机重试机制？例如 A 调用 B1 ，超时 1s ，换机调用 B2 ，又超时 1s
再者，是否有链路追踪，traceid 之类，分析超时前后上下文日志

坐标 wxg ，整个 wx 全是 c++

手里有大量优惠券，出售腾讯轻量云服务器，1c1g ，每月 25 ，250/年，其他配置也可以出

我这里有很多腾讯云代金券，都不知道怎么花。。。

正好最近在做一个海报中心项目，当时做方案时也是在考虑前端生成还是后端生成，所以这个问题我也回答下
我们的产品形态是小程序
1 、前端生成
优点：对后台友好，由于我们项目后台都是 C++，要找一个画图的库还是比较麻烦，前端合成可以降低后端开发压力，其次可以充分利用客户端计算性能，灵活
缺点：就像上面说的，需要考虑不同机型适配，字体问题，其次，要考虑前端生成的海报如何传给后台？传二进制流？还是合成后上传 CDN 再给后台？再者，由于我们还支持用户上传图片，小程序里可能支持性不够好
2 、后台合成
优点：可控性，可靠性，统一性更好
缺点：开发成本较高
最终和前端同事讨论比较，还是选择后台单独写个合成图片的服务，前端使用 svg 渲染海报模板，用户编辑后，再把 svg 转 json 传给后台，后台合成图片并上传 cdn，返回给前端 cdn 地址，最终，经过优化，合成的速度基本控制在 1~2s 。
目前我们海报中心小程序已经在灰度中，支持特殊字体，好友码，上传图片等功能，如下图
https://wx.gtimg.com/resource/feuploader/202102/b540d53198dd75d1b2c2d9cad6453014_1080x2337.jpg

@AmosAlbert 看看这个，除了黑白，无其他色彩，个人一直用 https://xujimmy.com/

本人本科通信，研究生光学，15 年毕业，第一份工作 python+php 两年，后来 java 1.5 年，现在 c++半年，都是大厂，都是入职现转的，LZ 体会下

感谢上述各位大佬解答，很有参考意义

@goodboy95 不用想那么复杂哈，这里就是写 sql 时为了拼接，仅此而已

慢的问题大概清楚了，但还有个问题不太清楚
同一条 sql，explain 时，为何有时用了 create_time 索引，有时又用 mchcode 索引？

@GGGG430 嗯，这个是线上生产哦，不敢随便乱搞。。。
force index 可以强制让 mysql 使用哪个索引，单纯测试可以用，但不是这里的解放办法

@Sasasu 使用 create_time 时，是 1311 哦
最好情况下扫 1 行，正好 create_time 最大的那行，满足 filter 条件。最坏的情况，扫到 create_time 最小的那行，还是不满足 filter 条件，是这样吗？
然后 rows 的值，只有参考意义，但实际扫了多少行，是不知道的，是这样吗？

@GGGG430 嗯，这里我也有这个疑惑，用 mccode 索引或者 create_time 索引，rows 都差不多，但查询时间相差巨大，所以解读 explain 时，关键是看哪个字段？ ref ？ rows ？

@GGGG430 这是用 mchcode 时的 explain
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+
type | possible_keys | key | key_len | ref | rows | filtered | Extra |
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+
ref | mchcode | mchcode | 63 | const | 1312 | 0.27 | Using index condition; Using where; Using filesort |
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+

@Sasasu 哦好像明白了，因为有 limit 1，所以过滤到一个就结束，假如没有 limit 1，索引又是 create_time，估计会扫全表，或者根本就没有满足 filter 条件的数据，也会扫全表。是这个道理吗？

@GGGG430 你说的有点问题，explain 的这个 filtered 字段，是百分比。。。当用 mchcode 索引时，这列是 0.27

@Sasasu 按你的解释，那我这 sql，由于有 filter，如果 mysql 使用了 create_time 索引，那必定会扫全表了？因为必须得一条一条的按 filter 过滤

@lasuar 为啥要把排序去掉再 explain? 这样 explain 出来的结果，对原 sql 有指导意义吗

@GGGG430 嗯，感谢指导，这些道理我也明白，尽量不要把运算搞到 sql 中，但这里的问题不是因为这个运算引起的，因为换使用 mchcode 索引时，查询仍然很快，使用 create_time 就很慢