@LeegoYih 对的，现在采用的是异步的方案，慢慢去消费封禁用户的帖子

展示的数据是以帖子为纬度的用户信息。
然后附加用户表的筛选条件。

发现问题了，索引字段默认值为 0 的时候，是不展示出来的

谢谢大家了

我这边测试了下，服务器 curl 走的是本机服务器。

现在正在操作用 nat

后端服务器是有公网 IP 的，我 curl 查看下 IP 地址来源应该可以定位到具体走不走负载均衡吧

以前看过这篇文章，觉得讲的蛮有道理，
这个东西本来就是一个取舍。
就看公司层面注重什么。


为什么要旗帜鲜明地反对 orm 和 sql builder 。

https://xargin.com/you-should-avoid-orm-and-sql-builder/

大家思想碰撞，搞不好就出来火花了

平时会对竞品进行分析，然后从技术角度会发现人家有些需求设计的特别精妙。
看着还是蛮有意思的。


坐标成都。
技术这条路还是在接着走，
但是看招聘，再往上的萝卜坑已经不多了。

最开始负责业务是类似于巨量引擎这种 adx 广告平台，当然是比较小型的，这个就需要比较深厚的行业相关背景，侧重点是 to b 的。这种基本上路线就是比较明确的。有相关范式在里边。

现在是 to c 的，比如出了一个需求点，如果来评判这个需求点的价值？
先出需求，后埋点查看数据，这种就存在迟滞性。

如何来预估这个需求点的价值，现在更多的还是有点偏向于感性的，

其实是想作为一个技术，从产品角度查看问题。

技术层面现在还是比较明晰的
比如我们现有业务基本上完全是 mysql 生扛，如果想优化的话，就必须深入 es 相关中间件了。
但是公司现状是不太需要的。


而有些需要实现的功能，与现阶段架构不相符的。
另一方面，公司的业务+数据都是在我这里的。对一个功能是否合理，我心里边是大概是有一个评判的，但是没有话语权。


所以就比较困惑，如果是自己主导一个项目，哪些迭代出来的功能是有意义的，那些是无效的。
基本上已经脱离简单写代码这个范畴。

从推广= > 产品=>技术=>变现 这个闭环，
所谓的把控作用

说的比较没条理，
现在心里边很乱

我们虽然调大了服务器的配置，但调大以后压测 10 分钟 20 万人和 4000 医护在线，服务器承载 20%都上不去，但前端页面会变得非常慢，基本上 10 几秒才能打开

关于这点，你们可以把 web 服务器放到单独的服务器上边，前置一个负载均衡，然后你们就查看外网带宽的负载情况，不够就加带宽。然后就是静态资源放到 oss 上边加 cdn 。

尽量把前后端拆分开来，这样的话，职权更清晰，更容易排查问题。

善用日志，负载均衡有日志，第三方 oss 也是有监控日志的，分析下就定位问题了。

一般我排查思路是这样的，
首先配置 nginx 日志，
接着就是 shell 脚本对 nginx 超时时间进行排序
查找超时且请求时间比较长的接口，
这时候你就要分析造成这种情况的原因了，
如果可以加缓存的话，就引入缓存，
其实就是查看数据库的查询情况，explain 一波。


一般情况下都是数据库使用不当引起的。
如果没法优化的话，那就稍微花点钱整个数据库主从分离。
服务器也是可以用平台的弹性伸缩。

基本上以上方法用了还不管用，
那就要考虑你们设计有问题了。


像这种业务应该不太会牵扯到多表联查这种情况

用户端用户注册 //这个没啥好办法，直接数据库硬抗。
进入页面绑定自己身份证号手机号乡镇信息等个人信息 //这个环节加个 redis 队列，异步写入库操作。laravel 还是非常快速支持的。用户同步信息之后，把核心信息写入 redis hash 或者 string 都可以
前端凭借身份证号直接生成个人二维码， //这个环节对后端直接走缓存
向医护人员出示二维码，1 个小时需要做 40 万人口的核酸；//这个地方就完全走 cdn


像这种业务是非常适合引入 redis 这种缓存的。

大概查看了下，确实是没有联合索引的问题，是这优化了下，将改接口优化到查询时间在 400ms 左右，然后发现其他接口查询效率降下来了。头大。

@encro 我理解理解，我感觉我又有点理解出错了。

现在就是采用主从库，我好像有些明白了，首先 mysql 在执行过程中，仅仅会从众多索引中选择最合适的一条索引进行匹配。
那么我们准备这种情况就必须联合索引。联合索引的话，就必须按照区分度大小选择合适的 ，像我这种语句必须按照区分度比较大的，且是基础查询组合联合索引。

联合索引中字段如果是=这种等值查询的。
比如 联合索引（ a,b,c ）
那么 select * from test where b=1 and a=1 and c=1,在这种情况下，a,b,c 都是可以命中索引的。
如果这种 select * from test where b=1 and b>1 and c=1 ,在这种情况，c 是不能名字索引的。

这个概念我理解的有偏差，所以我才把应该用联合索引的地方，全部走普通索引。

https://tech.meituan.com/2014/06/30/mysql-index.html

这是美团关于慢 sql 优化文章，我现在的索引，基本上属于普通索引，下一步就是进行联合索引的设计。