mysql负载高怎么办 mysql负载高优化

mysql单库负载过高的处理方式

请点击输入图片描述（最多18字）

经常混迹于技术社区，频繁看到这个题目，今天干脆在自己博客重复一遍解决办法：

针对mysql，sqlserver等关系型数据库单表数据过大的处理方式

如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；然后考虑分表 ；然后考虑分库。

这个题目是我所经历过的，我做的是GPS应用，早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种：表分区。 表分区的优势是，如果表结构合理，可以不涉及到程序修改。也就是说，对程序来讲依然是单表读写的效果！

所有轨迹数据存入到一个巨大的表里。有多大呢？

最大存储量超过10亿行。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹，所以线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力。  

每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截

这张大型单表设计要点：（一个聚集索引用于写入，一个联合索引用于查询，没有主键，使用表分区）

明确主键用途：

真的需要查询单行数据时候才需要主键！

我采用无主键设计，用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键，压测写入超过5亿行的时候，写入性能缩减一半

准确适用聚集：

写入的数据在硬盘物理顺序上是追加，而不是插入！

我把时间戳字段设置为聚集索引，用于聚集写入目的设计。保证硬盘上的物理写入顺序，不浪费性能用于插入数据

职责足够单一： 

用于精准索引！

使用时间+设备联合索引，保证这张表只有一个查询用途。保证系统只有一种查询目的：按照设备号，查询一个时间段的数据。

精确的表分区：

要求查询时候限定最大量或者最大取值范围！

按天进行表分区，实现大数据量下的高效查询。这里是本文重点，按照聚集索引进行，可以让目标数据局限在更小的范围进行，虽然单表数据上亿，但是查询基本上只在某一天的的几千万里进行索引查询

每张表会有各自的特点，不可生搬硬套，总结下我这张表的特点：

只增，不删，不改！

关于不删除中：每天使用作业删除超过30天的那个分区数据除外，因为要清空旧的表分区，腾出新的表分区！

只有一个业务查询：只按照设备编码查询某个时间段

只有一个运维删除：删除旧的分区数据

这张表，是我技术生涯中进步的一个大阶梯，让我我体会到了系统架构的意义。

虽然我的这张举行表看似只有4个关键点，但是这四个非常精准的关键点设计，耗费了我一个月之久！正是这么足够精准的表结构设计，才撑起了后来压测并发量超过3000的并发写入量！压测的指标跟数据库所在的硬盘有直接关系，当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境

关于后来为什么没有更高的实际应用数值，是因为系统后来改版为云架构，使用了阿里云，更改为写入性能更高的非关系型数

相关问答

Q1: Mysql占用CPU过高如何优化

CPU占用过高诊断思路

mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看详细情况

CPU主要消耗在mutex争用上，说明有锁热点。

采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更详细的API调用栈

Innodb在读取数据记录时的API路径为

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》  _L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。

而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。

Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。

当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。

解决方案

将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。

修改my.cnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的操作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

Q2: mysqlcpu跑不满

开APP

Mysql数据库高CPU问题定位和优化 原创

2020-05-30 19:33:37

5点赞

yw804909465

码龄11年

关注

本课程mysql负载高怎么办的主旨及目标

•导致mysql数据库CPU高的常见原因

•常见定位问题的方法

•一般定位步骤

•数据库注意事项

导致mysql数据库CPU高的常见原因

占用CPU过高，可以做如下考虑mysql负载高怎么办：

1）一般来讲，排除高并发的因素，还是要找到导致你CPU过高的哪几条在执行的SQL，show processlist语句，查找负荷最重的SQL语句，优化该SQL，比如适当建立某字段的索引mysql负载高怎么办；

2）打开慢查询日志，将那些执行时间过长且占用资源过多的SQL拿来进行explain分析，导致CPU过高，多数是GroupBy、OrderBy排序问题所导致，然后慢慢进行优化改进。比如优化insert语句、优化group by语句、优化order by语句、优化join语句等等；

3）考虑定时优化文件及索引；

4）定期分析表，使用optimize table；

5）优化数据库对象；

6）考虑是否是锁问题；

7）调整一些MySQL Server参数，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；

8）如果数据量过大，可以考虑使用MySQL集群或者搭建高可用环境。

9）可能由于内存（泄露）导致数据库CPU高

10）在多用户高并发的情况下，任何系统都会hold不住的，所以，使用缓存是必须的，使用memcached或者redis缓存都可以；

11）看看tmp_table_size大小是否偏小，如果允许，适当的增大一点；

12）如果max_heap_table_size配置的过小，增大一点；

13）mysql的sql语句睡眠连接超时时间设置问题（wait_timeout）

14）使用show processlist查看mysql连接数，看看是否超过了mysql设置的连接数

一般定位步骤：

   1】首先看看内存 free –m

目前看没有问题，1G的空闲

2】好了，用我们的必杀技，top看看资源消耗

可以看到服务器负载很高，mysql CPU使用已达到接近400%，基本可以看出mysql是可以进行优化的

3

Q3: mysqlcpu平均使用率

MySQL是一款常用的关系型数据库管理系统mysql负载高怎么办，它的 CPU 平均使用率指的是 MySQL 进程在某一时间段内 CPU 的平均使用率。通常情况下，MySQL CPU 平均使用率应该保持在合理的范围内，过高的 CPU 使用率可能会导致 MySQL 性能下降。

如果mysql负载高怎么办你想要查看 MySQL CPU 平均使用率，可以使用以下方法：

使用 MySQL 的状态监控工具：MySQL 提供mysql负载高怎么办了一些状态监控工具，如 mysqladmin、mysqltuner 等，这些工具可以帮助你查看 MySQL 的 CPU 使用情况。

mysql负载高怎么办的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于mysql负载高优化、mysql负载高怎么办的信息别忘了在本站进行查找喔。