事件记录：SQL问题导致的Mysql服务器资源耗尽，以及一系列关联问题

       mysql服务器性能：8核32G

       单表最大数据量：28万

       TCP同时连接数：5434

       TCP框架使用Netty

       主从同步未开启，高可用也未开启，只开启了主从复制，使用单点数据库。

       后台服务使用微服务，并docker管理。

       系统整体架构包括：终端后台（TCP链接）、Web/APP后台、中间件rabbitMQ、radis缓存。

       终端设备通过TCP连接到终端后台，每一分钟上报一次位置数据，期间还有链路检测包、语音包、报警包等等。终端数据在后台做解析和持久化，并作为生产者使用rabbitMQ推送数据到APP后台。Mysql的压力集中在终端后台的数据插入、APP后台数据查询与更新。

       终端连接数达5000+的时候，web端和APP端出现爆卡，实时位置和报警数据无法推送。首先梳理数据流向，定位可能存在的点在终端后台数据插入、rabbitMQ数据推送和数据消费。观察MQ管理端，发现单队列消息累计已达到十五万，MQ消费能力入不敷出，消息量还在继续增加。观察Mysql服务器资源占用情况，发现CPU占用率已经持续在300%以上，峰值达到400%。那这里应该就是问题所在了，数据库服务器性能已经面临极限。

       按理来说，8核32G的配置，即便是单节点服务器，十万级数据量不应该出现性能瓶颈，那问题应该出现在SQL上面。下一步，监控Sql执行状况，开启慢查询。SQL日志监控最好查问题用的时候再打开，因为数据量记录会非常大。
       查看日志记录是否开启：show variables like "general_log%" ;

       设置开启日志记录：set global general_log=ON;

       查看日志发现有大量的递归查询和left join联表操作，5分钟内单挑查询指令执行次数达到28W。因此立即先解决此处。修改完成后资源占用率有些许降低，但是依旧保持在200%以上。继续查看日志，分析SQL，打时间戳发现有些语句单条执行时间达到300ms，修改。

       此时又发现rabbitMQ消费性能很低，只有个位数每秒，因为消费逻辑与Sql插入逻辑关联，继续排查SQL，修改执行时间长的语句。并开启多个MQ客户端，多线程消费。最终MQ消费回复正常，单线程3客户端达到100/s左右。

       总结：1、系统稳定性极差的情况下，如果能排除掉网络原因，首先做数据流向梳理；

                  2、确定可能堆积数据的位置后，查看服务器性能，定位到某个服务的资源消耗；

                  3、如果确定数据库服务的问题，通过开启性能监控、线程池、分析Sql日志等几个方面来确定问题所在。

                  4、修改高耗时SQL后，尽量模拟高压环境测试，确定系统状态稳定。