一个比较常见的情况是，mysql 判断走索引的成本太高，还不如扫全表。

一个典型的案例是，你的查询命中了索引 2/3 的数据， 如果走索引得先扫 2/3 的数据，然后这 2/3 的数据还得回表。相当于 扫了全表的 4/3 数据。

但我不太确定这会不会 导致 force index 语法也不生效

这个业务入口会为接口带来多少的 qps 增长？
===== 这个基于原有页面的曝光，和类似入口的点击率来估算，实在不放心可以灰度
这个接口能抗住多少 qps ？
===== 压测
这个业务要上缓存的话，预计会带来多少缓存占用？
===== qps 都有了，可以估一个占用上限出来。 当然，有些数据是公用的，只要缓存一份，有些用户独占的，看你访问用户数，再结合你的缓存过期时间来估算。比如缓存时间一天，一天内有 1 万用户访问这个接口，每个用户需要缓存数据量。
现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
===== 看 redis 缓存的数据类型和数据大小，配合历史的 redis 监控图标数据来做分析估算，比如流量增加一半，假设 redis 线性增加会到一个什么量级。
现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
=====这个没多少经验，暂不做回答。
业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
=====正常来说思路还是压测，但是如果考虑这么多，那为了真实需要在生产压测，风险比较高。
这个业务的性能瓶颈在哪里？怎么查出来？ 等等
===== 我个人两种思路，第一种直接看代码，分析这段代码有哪些外部调用 /依赖，然后再从中挑出风险最高的部分。 另外一种压测配合火焰图或者 benchmark 类工具实际运行分析。

楼主如果买房无望，只考虑每个月存多少钱的话。 我再提供一个考虑的角度，就是生活舒适度，可能你觉得住城中村已经没舒适度可言了。 但是住宿环境还是有较大差别，另外一个就是通勤等成本。
像北京、深圳这样的城市，租房成本较大，很多人为了省成本，单程通勤时间长达一两个小时，在员村通勤应该还好，而且千元左右的城中村，环境应该都还可以，至少应该不是暗无天日的深巷握手楼。

如果其他环境没问题就生产有问题，那理论上是程序的问题概率很小。

如果是我不会重点关注项目日志(因为你也不熟)，而会在对比环境的差异：
1. 生产和测试的服务配置有没有可能影响？ 启动参数一样吗？
2. 检查各环境服务器配置和负载

进行不同环境的对比，找出不同项重点排查

我是后端，我的看法不是前端难学也不是后端难学。

而是这两种职位对人的思维要求不一样。
后端重数据算法性能，因为所有客户的请求都集中到后端，小毛病也会被放大，重点在怎么高性能地处理和查询数据。

而前端因为逻辑放在用户本地浏览器或者手机，调用的是每个用户自己的资源，性能相对要求没后端那么高。
以我有限的接触前端的经验来看，前端很多精力会放在调整交互上，控制一些组件的显隐，组件之间的排版会不会挤压，组件层级优先级啥的。

简单来说，我觉得前后端都不难学，但是思维和处理的问题不是同一个领域，所以会觉得很麻烦，很难搞。

1. 不正常，建议先学精一个领域再考虑要不要做全栈，新人一开始就全栈只能每个领域都浅尝辄止。感觉你老板是省钱在职场 pua 你。
2. 当你觉得在这里地方得不到成长的时候，就得考虑换个地方。找下家之前想清楚自己需要什么，不要盲目从一个坑到另一个坑。
3. 新人阶段，暂时不要想着应用 数据结构和算法，弄清楚常见数据结构的优缺点适应场景，以及理解常见算法的逻辑原理，以后你还坚持做程序员会用到的。
4. 这好几种想法有哪些优缺点？分别适合什么场景下使用？当前这个需求的特点是什么？想明白这些就知道这个问题的答案了。 如果和 茴 字的四种写法 一样没多少区别和意义就不要浪费时间精力在这些事情上。

正常啊，这些网站不求着人用，没有必要投入过多技术成本去做体验优化和兼容。

楼上正解，用 sts 临时授权就可以。生成临时的密钥给前端，前端直接传上阿里云