在业务服务提供能力的时候，常常会遇到CPU飙高的问题，遇到这类问题，大多不是数据库自身问题，都是因为使用不当导致，这里记录下业务服务如何定位数据库CPU飙高问题并给出常见的解决方案。
CPU 使用率飙升根因分析
在分析CPU使用率飙升根因前，先介绍下CPU使用率公式：
单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量
可见，CPU使用率与【查询执行的平均成本】和【单位时间执行的查询数量】线性相关，而这两项就是我们常说的慢SQL以及数据库QPS。
所以，CPU使用率飙升可归纳为以下两点：
(1) 大量的慢SQL占用了cpu资源，拖垮了数据库，这类的慢sql常常表现为：查询的数据量过大，全表扫描、锁抢占甚至死锁、复杂查询等。
(2) QPS过高，本质上是数据库的承载的流量过大。
QPS过高问题定位及解决
如果想判断是否是因为QPS过高，导致CPU飙升，最好的方式是查看QPS曲线和CPU曲线是否保持一致，如果QPS曲线基本和CPU曲线保持一致，此时可断定CPU飙升必然存在QPS过高的原因。示例如下：
接下来就是确认是哪些SQL的QPS过高。对于MySQL数据库，可以通过root用户登录数据库，然后执行’SHOW PROCESSLIST’命令查看。
确定了高频SQL，接下来就是对业务进行分析，确认下为什么会执行如此频繁的调用并给出优化方案。
(1) 使用批量操作，将多个操作合并为一次请求，但此种方式需要考虑是否可以一次批量的数据有多大，避免造成慢SQL。
(2) 尽量从缓存中获取常用的查询结果，减轻数据库的读写压力。
(3) 尽量优化查询，减少查询的执行成本（逻辑 IO，执行需要访问的表数据行数），提高应用可扩展性。
(4) 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
(5) 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。(读写分离)
(6) 升级实例规格，增加 CPU 资源。(首先确认是资源不足，然后才考虑扩资源)。
慢SQL问题定位及解决
一般情况下，数据库都会提供慢查询日志，所以只需根据慢查询日志来确定慢SQL接口。以MySQL为例，可以通过root用户登录数据库，执行SHOW VARIABLES LIKE 'SLOW_QUERY_LOG%'命令来查看慢日志的路径。
在指定路径下获取到慢查询日志后，接下来就是分析慢日志，确认慢SQL。
分析慢查询日志，发现有一条SQL的执行时间超过2S。进一步使用explain查看执行计划，发现执行时间的确很长。
确定了慢SQL后，接下来就是对SQL进行分析，确定下优化方案。关于数据库访问性能的优化可以参考笔者之前的文章，这里列举下常用处理方式：
(1) 减少数据访问。确认下是否使用索引，如果没有，看看是否可以补充索引。如果已使用索引，确认下索引是否生效或失效。
(2) 减少返回的数据。如果没有使用分页，确认是否可以使用分页。如果返回字段包含大字段或字段，确认下是否可以分表或仅返回需要使用的字段。
(3) 减少交互次数。确认下是否可以引入批量操作，或提高单次fetch数据的size。
(4) 减少数据库CPU开销。针对大量的计算，确认下是否可以转移到客户端执行。针对排序场景，确认下是否有优化空间。
(5) 针对读多写少场景，考虑使用读写分离的设计。
(6) 升级下机器的资源配置。考虑是否机器的本身性能较低，不符合业务需求。
总结
本文介绍了数据库CPU飙高问题定位及解决，重点介绍了如何判断慢SQL和QPS过高。需要说明的是，以上内容是笔者基于网上的知识整理的内容，笔者并没有太多这方面的实践经验。但是，上述定位问题的思路和解决方案是有参考价值的。比如使用缓存减少数据库读写次数、批量操作、机器资源配置升级等方案，笔者在实际的产品维护中，都有使用。
参考
https://www.cnblogs.com/jyc123/p/16498247.html 数据库CPU使用率100% 排查记
https://blog.csdn.net/yw804909465/article/details/106445902 Mysql数据库高CPU问题定位和优化
https://www.cnblogs.com/wyy123/p/9258513.html MySQL CPU 使用率高的原因和解决方法
https://www.modb.pro/db/31741 mysql QPS 过高问题处理
https://www.cnblogs.com/wyy123/p/9258513.html MySQL CPU 使用率高的原因和解决方法