标签：关联 后台 结果 处理 根据 red 高级 strong 更新
一、数据库优化
一般来说，当一个请求超过200ms,就需要优化了，当前这不是绝对的标准，具体看业务场景。
sql优化一般包括
1、是否命中索引
2、设计是否合理
3、关联查询是否合理
实在数据量大，只能在拆分了。如果需要同时插入许多数据，尽可能使用 BulkCopy 操作以提升性能。
使用云数据库的监测慢查询、MiniProfiler等
1、重复调用
在代码当中，重复的调用执行sql、计算方法等，比如在循环的方法当中，根据id查询数据库，循环100次查询100次sql，这种是很崩溃的做法，应该是在外面直接统一查询；
在做事务处理的时候，一些查询动作需要先处理查询，最后在执行事务，避免事务时间过长，导致死锁；
避免循环创建对象；
使用StringBuilder做字符串连接等。
使用MiniProfiler进行监测；
很多业务逻辑不复杂的功能，却响应很慢。往往都是直接就调用一些已经存在的方法，导致整体响应变慢，或者可能就需要一两个字段，结果把所有的字段都处理了。其实就是避免查询的时候直接select *，返回的时候不要整个实体对象返回。
缓存也是优化中最常用的，效果提升最明显的，成本也不大。对于缓存，也不要滥用，不是所有场景都可以靠堆缓存来提高性能的。
首先对于实时性要求不高的业务场景可以优先使用缓存，也不用太考虑更新的问题，自然过期就行。
实时性要求高的业务场景，用缓存一定要有完整的缓存更新机制，否则很容易造成业务数据和缓存数据不一致的情况。
推荐使用redis，支持分布式.
有些逻辑，不需要实时反馈给用户、或者耗时的那就可以采用异步的方式在后台进行处理。
可以使用消息队列rabbitmq、后台服务hangfire等
加机器是最后的终极大招了，并发量上去的时候，你在怎么优化单机器和单数据库抗并发能力也是有限的，这个时候只能水平扩展了。
做负载均衡等
标签：关联 后台 结果 处理 根据 red 高级 strong 更新
原文地址：https://www.cnblogs.com/lyl6796910/p/13935059.html
