数据库性能优化简要方法
常见的性能问题，往往是欠缺性能考虑引起的，响应巨慢的同时，硬件利用率可能5%不到，这类问题也是此次锅叔主要讨论的。
以下部分内容由 小红书（www.xiaohongshutuiguang.cn）转载提供
经验上来说，对于性能问题的监控预警是难于解决具体的性能问题的。实践中我们需要一些日常机制来筛查系统性能问题，避免病入膏肓。
数据库慢查询日志——是一个重要的监控途径，其中记录了耗时较长的数据库操作记录。可以通过手动或自动分析慢查询日志，筛查可能存在的性能问题，主流数据库都支持慢查询日志生成，具体的配置方式此处不做赘述。非统计类的数据操作通常应该在100ms以下。
接口性能监控——后台系统通常是通过服务接口向外提供服务的，前端页面或者移动设备是通过调用服务端接口来完成对应操作的。接口的粒度是大于数据库操作的，一个接口调用可能包含很多个数据库调用。接口性能更接近于用户体验，因为多数时候用户的一个操作动作会对应一个服务接口（如保存，确认）。在不存在慢查询的时候，接口性能可能也会不满足要求，可能的原因如，一个接口循环调用了1000次数据库操作，或者调用了一些第三方接口等。对接口的性能监测原理上就是用调用结束的时间减去进入的时间点计算总耗时，并把这个耗时记录下来，以便时候筛查。Spring的切片能力可以方便的实现该需求。非报表，导出类接口，锅叔认为应当在1秒内完成为佳。
消息队列——如果你的系统中使用到了类似消息队列的机制，对队列中排队的消息数，同样应当进行监测，消息如果发生了堆积，说明在这个阶段内，系统的整体消费能力已经不能满足输出要求了。
以上三个监控维度是互不重叠的，应该同时进行。
二、性能问题的定位
除了数据库慢查询日志可以明确提示具体SQL缓慢外，上面另外两种情况所能直接提示定位到的粒度都比较大，对应一个接口或者一段处理过程代码。
定位更细问题的具体方法也很容易想到，即分段输出各阶段的耗时。如对于一个100行的方法，可以在第30，60，100，分别计算并日志输出这3段执行耗费的时间。重复进行，就最终可以定位到将问题所在。
性能问题的定位需要有一些性能常识，所谓性能常识即，通常做一件事情需要完成的时间，不用很准确，但量级要清楚。比如一次数据库操作，一般在数十毫秒，与内存的交互在纳秒或者微秒间，与第三方系统的接口可能在数百毫秒到几秒之间。有了这些经验我们才能够对耗时是否合理有个基本判断。比如对于一个50毫秒的数据库操作，循环100次就是5秒，已经很慢了，可以考虑是不是可以合并成一次批量操作。
三、应用性能优化方法
合并远程调用——根据经验，实践中因为循环进行数据库操作，或对第三方系统接口进行循环调用，是引起性能问题的非常非常常见的原因。对于此类问题的优化方式通常就是优化调用的方式，使用批量操作。例如，如果需要去数据库中查询锅叔近一年的打卡记录，可以用准确日期，查询365次，也可以用时间范围一次查询出365条，后面的方法肯定比前面的快很多。如果方法比较复杂，冗长，可以从中抽取所需的公共数据，进行统一的批量查询取出，放入内存备用，会比哪里用到哪里查要快很多。同样写入，修改操作，也尽量批量进行。
使用缓存——对于访问频率较高的数据，可以在内存中存储，利用内存存取要快于硬盘很多的特性，来进行访问加速。常见的场景如各种计数——锅叔的文章有多少次浏览之类。
多线程并行——通过多线程把串行修改为并行。例如与设备通信查询状态，逐个查询和并行同时向设备查询，后者要快得多。现实中多数的操作耗时是在IO上，因此多线程方式可以有效提高性能，避免“空”等。多线程并行需要注意做好线程同步。
以上部分内容由 小红书推广（www.xiaohongshutuiguang.cn）转载提供
中间结果——本质可以理解为数据库层次的缓存，如果一些结果从全量记录中计算数据量巨大，耗时必然很长。可以分批计算，存储中间结果。以加速数据取得。如计算锅叔家近一年的总支出，可以通过每笔记录加起来，也可以每个月算一次，这样只需要查询近12个月的支出加起来就可以啦。
