接口大并发时慢

git地址：https://github.com/ShareCookies/ssm-springBoot/blob/master/%E6%95%B0%E6%8D%AE%E5%BA%93/sql/%E4%BC%98%E5%8C%96/%E8%AF%8A%E6%96%AD.txt

问题定位：
    首先你要定位到问题所在：
        1.网络问题（访问到应用的过程问题）
            诊断方式：
                方式1：换终端换网段等进行快速测试
                方式2：tracert、ping等命令测试
        2.应用问题，
            追踪方向：
                1.应用并发量过大
                    附：跟cpu有关，通常tomcat并发量200为佳
                2.应用性能（服务器cpu，内存，io，进程等）
                    附：看代码逻辑中是否有大I/O,高强度计算，大并发
                ...
        3.数据库问题。
            诊断方式：
                并发模拟或实际情况下，通过下面的追踪方向来诊断。
            追踪方向：
                1.锁等待（如果数据库性能消耗不高，此时通过事务等来判断是否锁问题导致慢sql。）
                    介绍:
                        ../事务/锁机制.txt
                    诊断方式：
                        查询正在执行的事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G（推荐mysql客户端执行\G便于复制出来查看）
                        ../事务/释放锁.txt
                    解决方案：
                        goto：../事务/锁机制.txt InnoDB行锁优化建议
                2.数据库性能不够（优先看数据库性能，因为诊断较快。）
                    诊断方式：
                        1. 监控服务器性能：
                            使用top等命令监控linux服务器性能。（cpu，内存，平均负载，进程占用资源情况...）
                        附 2. 数据库连接数是否充足
                            Navicat Monitor
                        附 3. 查看数据库线程情况： 
                            https://www.cnblogs.com/duhuo/p/5678286.html
                            通过 show processlist 来判断数据库性能，连接数，慢sql堆积，网络状况等各种情况...
                            附：
                                https://www.cnblogs.com/remember-forget/p/10400496.html
                                https://blog.youkuaiyun.com/dhfzhishi/article/details/81263084
                                https://www.cnblogs.com/hixiaowei/p/10934484.html
                        以上诊断方式通常结合起来使用，1快速看服务器性能，2提到的工具操作简单，3综合能力较强。
                            
                        附：
                            Navicat Monitor等监控工具。
                    解决方案：
                        1.增加性能：
                            1. 服务器太low，换更好服务器
                            2. 闭眼开始集群或读写分离。
                        2.sql优化（问题优化）：
                            先找出导致问题的sql语句，例有问题的时间段有那些慢sql等。
                            诊断方式：
                                1：并发模拟，或发生问题时现场诊断。
                                    附：
                                    并发模拟工具：
                                        https://github.com/yuyumyself/UtilsProject/blob/master/Utils/src/main/java/com/china/hcg/thread/ThreadPoolUtilsDemo.java
                                2.
                                    通过druid（判断那个类型sql慢），mysql慢查询（具体是那个sql慢，有参数的）等来判断是那个sql有问题。
                            解决方案：
                                1.走缓存
                                    附：缓存部分清空。失效后能否在业务低峰期在重新加载Redis缓存。
                                2.优化代码逻辑，根据所需数据，看看能否少掉这个sql或少掉部分sql。
                                3.sql优化：
                                    1. 通过explain优化sql，尽量全部走索引。
                                    2. 少关联表，不要超过3个表的多表关联。
                                        关联越多，影响因素越多，且数据量是递增级别。
                                    3. 复杂sql拆分成多个SQL查询。
                                        这样可以避免语句相互之间影响。
                                        让语句简洁易懂，好维护才是王道。
                                    4. 通过程序把查询结果带入，通过程序合并sql结果，让程序来负担一部分数据库压力。                            
        例：
            例1接口大并发时慢：
                1. 是没问题的
                2. 应用也是不会有问题的，应用服务器性能稳定，且代码逻辑中没有什么大io操作，或计算等耗时操作等。
                3. 那么问题应该就是数据库层面问题。
                思路：
                    优先看数据库性能，因为诊断较快。
                    druid清空，开启慢sql，然后并发模拟。
                    发现数据库性能消耗是较高，且druid（判断那个类型sql慢）和慢sql（具体是那个sql慢，有参数的）中均发现大量耗时sql。（这种情况实际环境中更为明显）
                    因为均为查询接口，所以无需关心锁的问题，那么此时就尽量进行查询sql优化来进行初步调整。结果并发模拟和实际是得到了不错结果。
                    如果未得到较好结果在尝试缓存，代码逻辑优化，集群等方案，因为问题总得解决如果不解决直接上这些方案，只是进行了问题掩盖，雷还是在的。
                附：
                    1. 为什么只是查询sql无需关心锁问题：
                        因为只是查询，那么也只会加共享锁才对，而共享锁下查询可以并发。
                        附：
                            要查询的数据，被别的给加了排他锁。
                            如果是这种情况，那么就要整个应用查找哪里会有更新语句，然后尽量缩小其锁定范围。
                    2. 大量慢SQL堆积导致CPU资源打满，整体数据库的性能下降。
                        当未走索引或多表关联等进行大量查询时，此时数据库会调用cpu资源在硬盘中进行大量的io操作和查询，这是很耗费系统资源的。
                附（废弃）：
                    接口的核心sql语句单独执行发现并没有很慢，那么此时可得到什么结论了：
                        嗯，核心接口表并没有被锁。但数据库性能不够并不能完全排除