@drymonfidelia #28 在测试环境删掉索引不是为了测试 EXPLAIN 是否能命中索引嘛。。。 跟快不快又啥关系啊。。

可能确实是你认知问题。。
app 本身是需要兼容老版本的，你一个接口返回太多东西以后怎么兼容，后端做版本判断？

已经要到卖树的程度了吗

8 年经验面什么级别啊？ 资深开发？ 还是专家

有什么不敢
1999 - 唯唯诺诺
2009 - BTC 重拳出击

过于简洁了吧

@drymonfidelia #25

当然是在测试环境测试啊 锅锅。。。 你直接干生产啊。

你这排名也到不了前面，服务器成本都赚不回来。

当然是留言板了 https://i.imgur.com/agAJ0Rd.png

猜测问题来自于滥用联合索引导致的
你可以把整个表的除唯一索引之外的联合索引删掉，按照单字段索引创建问题应该可以顺利解决。

这种相当于全部重构，整体流程不是这样的，这种项目对公司没有产出，现有功能是正常运行的，随时可能停止。
类似的活我干过，主要是为了性能优化，原来项目也是类似的需求，只不过原始版本太老了，性能差。
1.先用写一个代理工具，先收集一下请求流量的多少和接口的响应速度以及请求的高低峰。
2.了解现有项目接口的串行调用逻辑，按照业务系统操作流形成接口脑图同时制定重构计划（方便测试和定位问题）。
3.了解老系统用了哪些中间件，比如缓存/阿波罗/队列消费之类的，这里需要做好迁移方案尽量一起动。
4.根据因为前期有了代理工具可以收集入参出参可以进行数据对比检查和测试。
5.上线后的调用逻辑是
客户端请求 -> springboot 重构系统 -> 老系统
未重构的接口走老系统返回的数据直接返回
重构的上线前期对比自己的数据结果和老系统的结果是否一致，一致正常返回，不一致返回老系统的值并告警排查，稳定一段时间后减少老系统的请求转发（也可以等项目整体上线全部稳定以后再整体切换）。

整体切换对中间件的依赖连贯性更好，但是会产生双倍流量负载，包括数据库和缓存需要考虑扩容

这是什么机霸 App 啊 https://i.imgur.com/agAJ0Rd.png

到底是什么理由必须买这垃圾东西啊。。。

@craftx #6 企查查看下股权比例即可，这是入职之前能了解的。

@craftx #5 入股多少看你的业务需要多少领域的合伙人和初始资金比例以及融资预估情况预留多少给稀释。
有一个前提是不管怎么样都不存在纯技术入股 资源入股，必须真金白银拿钱出来。
拿钱就有话语权，不然就是扯淡。

我选公司有一条准则分享给你，就是 cto 在公司是否占股，比例可大可小。
意味着技术上的话语权，意味着研发有渠道可以直接跟最大的 boss 对话，意味着技术在工作流程上是否有发言权不是纯粹的执行者。
有些公司甚至没有技术合伙人，只有所谓的技术总监岗位，这种绝大概率是坑。