公司的老项目，一个查询表单接口2.7分钟，表单大概有七个富文本和Tree结构的数据，富文本里的图片用得base64存的，现在富文本这张表数据量5个多G，整个接口涉及12张表。现在客户那边要求优化，难倒我了，有没有佬能给个解决方案
建议离职 
6 个赞
Tree结构异步查询，富文本图片写个脚本存oss吧
嗯看不懂你说的 但是建议是
1、业务层优化，列表页面不要展示太多数据
2、组织成宽表将一些基础数据合并成一张大宽表，建立好索引
3、富文本优化，将图片存到合适的地方不要放到mysql中，可以写个定时任务来做
4、暂时先提高服务器资源，上述步骤做完了看看情况，再做优化。
5、如果客户不同意，那就建议离职
Tree结构异步查询还好，富文本图片问题涉及地方太多，没办法改动存oss了
大改 得加钱
建个宽表，文件用对象存储
其实也可以，就是耗时耗力，得加钱，客户不同意 
不是列表，是详情表单页面，表连接的不多，涉及12张表最主要是因为 代码逻辑要处理的。富文本图片不放mysql处理比较麻烦费时费力，加钱客户也不同意。
宽表意义不大，涉及表多不是因为表连接，是代码逻辑要处理的。图片用对象存储改动太大，费时费力，加钱客户也不同意
加钱客户不同意，为难的就是我这种底层CURD工程师 
1 个赞
富文本表有什么字段可以分类处理一下吗，有的话分类分表处理一下？
PS：不加钱还想优化
首页分析接口耗时分布吧，是在sql查询阶段，程序处理阶段，是否有n+n的sql查询等
不加钱不好优化啊
多个查询的话，尝试下多线程吧，搞个并发，一个线程一个查询，查完再组装数据返回。至于富文本的话这个没啥辙，表的数据搞这么大也是少见的。。可以试下 redis 做中间缓存是否可行，要不就异步加载返回
什么玩意一个表单涉及12张表，我的建议是得加钱
这东西不太应该存到mysql里边
要么客户多给点时间开发，要么加钱。想无成本让提高查询效率，免谈。
好的，我反馈下领导吧，shi山代码让我来维护