MySQL导致CPU占用过高，如何优化？

谁在消耗CPU？

用户+系统+IO等待+软硬中断+空闲

祸首是谁？

用户

用户空间CPU消耗，各种逻辑运算执行大量tps
函数/排序/类型转换/逻辑IO空间消耗...UUCPU，导致系统调用什么是吗？哪些函数使用 CPU 周期？

IO等待

等待IO请求完成此时CPU实际上是空闲的例如vmstat中的wa很高。但当 IO 等待增加时，wa 不会增加（I/O 请求后等待响应，但进程远离核心）

影响

用户和 IO 等待消耗大部分 cpu

• 吞吐量减少量（tps） )
• 查询响应时间增加
• 慢查询数量增加
• mysql并发量突然增加也会产生诱人的效果

如何减少CPU消耗？

减少等待

减少IO量SQL/索引，使用适当的索引来减少扫描行数（需要平衡正索引收入和维护开销，空间换时间）改善IO处理选项 添加缓存/添加磁盘/SSD

减少计算量

减少逻辑运算量

• 不要使用函数以及可轻松扩展的应用程序服务器（如substr）和传输操作（如dateadd/） datesub、abs 等数学函数
• 减少排序 ，使用索引获取有序数据或避免不必要的排序
  例如，用 union all 代替 union，按索引字段排序
• 禁止类型转换 ，使用合适的类型，并保证传入参数的类型和数据库字段的类型绝对一致
  比如数字使用tiny/int/bigint等需要转换的，就必须转换在将它们传递到数据库之前在应用程序中
• 简单类型 ，尽量避免复杂类型，减少复杂类型带来的额外操作。较小的数据类型占用较少的磁盘、内存、CPU 缓存和 CPU 周期
• ….

减少逻辑 IO 量

• 索引，优化索引并减少不必要的表搜索

  索引，调整组合索引字段的顺序，去除选择性不好的索引字段等。

• 表，合理分区，适度冗余
  比如很少使用的大字段拆分成单独的表，很频繁的小字段对“参考表”来说是多余的
• SQL，修改SQL表示法，充分利用现有索引，避免不必要的扫描、排序等操作
  比如减少复杂连接、减少顺序、尽量统一一切、避免子查询等
• 数据types 如果够了，就减少不必要的大字段的使用
  如果tinyint够了，就不要一直用int，如果int够了，就别总用bigint，如果date够了，就不要一直用bigint总是使用时间戳
• ….

减少查询请求数量（不是数据库本身）

• 适当的缓存，减少缓存数据的粒度，适当存储静态和频繁请求的数据
  这样如用户信息、产品信息等
• 优化实现，尽量消除不必要的重复请求
  例如，防止同一页面多次重复请求相同的数据，通过传递参数来限制访问
• 合理需求并评估所需的产出比，合理消除极低的产出比要求
• ….

升级CPU

减少计算量后无法满足等待，CPU利用率还很高T_T该拿了 现在我们已经有了最后的王牌，升级CPU，我们应该选择更快的CPU还是更多的CPU？

• 低延迟 （快速响应），需要更快的 CPU（每个查询只能使用一个 CPU）
• 高吞吐量 ，同时运行多个查询，可以处理来自多个 CPU 的查询 中增益