1.后端接口优化相关：
- 关联查询的列表字段如果最终结果只来自一张表，可以先筛选出id字段，然后再查询所需要的字段（只select id或者用exists优化）
- 通过数据字段的冗余可以很好的优化一些查询，如下场景，现在要查询邮件（海量）的收件人信息，因为收件人往往是有多个，所以收件人信息是被以逗号隔开的形式放在了邮件表里，这个时候如果需要通过将收件人的邮箱或者地址作为搜索条件，那么只能用like ‘%%’ 去查询查询邮件信息，这样在数据量大的时候查询效率是很低下的。所以，这里将地址信息单独存放在了一张表中，另外原来的拼接字段也同时保留，这样查询的时候可以通过地址表过滤出对应的邮件id，而所有的查询字段都来自于邮件表（不用连表组装）。
- 代码优化步骤：
- 代码层面，有没有多层for循环，或者for循环的遍历项目可能十分庞大，有没有使用多线程，有阻塞的情况，有没有在for循环中使用数据库的访问代码。
- 数据库层面，用相关的插件，打印出所有程序流中接口调用使用到的sql, 逐条分析是否包含效率低下的查询。
- 组件层面，如果是使用了类似ng之类的中间件，如果代码和数据库层面的改动都调整到比较搞笑的情况下，此时可以查看这些中间件的日志，并且逐层分析原因。
这里记录一下遇到的一个很坑爹的问题，
项目在正式环境中出现了部分接口访问时快时慢的问题，这些接口在数据库访问和代码的优化都已经做到最优，但是仍然出现了有时候毫秒级返回有时候需要十多秒甚至二三十秒返回的问题。最终在nginx日志那里发现请求的到达时间有时候会变得异常的缓慢。起先我是十分怀疑是正式环境的网络有问题，像是那种不明波动，因为之前也确实出现过问题（但是修复了），不过如果是网络问题的话，为什么其它服务接口又能很稳定的调用呢。几经排查发现，接口慢在页面列表的项目需要加载图片的时候才会出现，场景就是每个列表的图片都是单独加载的，而且是加载的用户上传的原图，没有做任何的缩小，转码处理。正常的处理一般的都是静态化存放在ng或者特定位置，不过这次问题主要原因在minio的文件获取，在谷歌上也看到了类似的问题描述，说是minio对于多个小文件的读写会出现效率低下的问题，现场的情况是在手工上传了新文件后，文件获取速度会正常一段时间，而后又变得很慢，这就比较明显是minio的内部机制有不完善的地方了。后来通过升级minio发现提示说linux系统内核版本低，可能会影响性能，另外因为之前磁盘的空间不足，将minio的数据目录存改为了一个新的2.2T的挂载目录，然而启动命令并没有修改，所以这也有可能对minio的文件访问产生影响，所以这里还在做进一步尝试。（目前就是锁定这两个因素，如果还是效率低下，那么说明minio最新版本可能还是没有解决这个同时多个小文件读写的问题，结果会后续更新。。。）
另一个问题是，用户反应邮件列表查询有时快时慢的问题，这里邮件的总量大概在百万级，而邮件的解析工作是一直在进行的，只要平台有新的邮件解析任务插入了任务表中，应用这边就会不断的往邮件表里插入新的数据。这样必然导致索引也在逐渐变大，索引的维护成本也跟着上升，随之而来的问题是，数据的插入和更新都会变得效率十分低下。不过鉴于本系统主要的工作是查询和插入，对于插入操作来说，因为数据量本身巨大，并且用户也不需要查看实时插入的数据，所以这里将解析的操作改为只在用户的非工作时间进行。（进阶，当数据量大到一定程度，索引可能也不合适了，但是oracle对于千万左右的数据还是有比较好的支持，所以暂时咩有分表）
