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

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

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

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

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

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

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

最大存储量超过10亿行。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹，所以线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力。   每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截

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

明确主键用途：

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

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

准确适用聚集：

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

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

职责足够单一： 

用于精准索引！

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

精确的表分区：

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

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

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

只增，不删，不改！

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

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

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

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

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

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

IO过高是指输入输出过高了这个有许多原因都会导致mysqlIO过高了，小编见过apache处理数据缓存导致mysqlIO过高问题当然也有其它关于mysql本身问题导致mysqlIO过高的问题了，下面给各位整理总结一下关于mysqlIO过高处理办法。

<script>ec(2)</script>

1、日志产生的性能影响:

由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。MySQL的日志包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然，更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。

在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。

一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。

2、mysql内执行如下指令：

set global sync_binlog=500

当每进行500次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

set global innodb_flush_log_at_trx_commit=2

默认值1代表每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设置为2代表不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值设置为2只会在整个 *** 作系统宕机时才可能丢数据。

注：重新开机后，该指令失效。可在服务启动时，设置如上两项。

现象是，系统里的java连接mysql超时了，

于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况

发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子

用mpstat查看cpu情况

好明显，都在等io

用iostat查看io情况，%util的值，一直在80%，99%之间变化

以为磁盘有问题，用dd测下速看看

从上面的结果看，也还好，没问题

以为可能磁盘有坏道，用下面命令也扫了一遍，没问题

结果也没有坏的块，这个过程，很耗时。

用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的

想看看mysql，研究写哪个文件时，最耗时的

从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下

我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了

清了之后，再用iostat查看

%util一下子就降下来了，用iotop查看mysql进程的io也下降了

cpu的iowait也下降了

定义一个事件，让mysql定时清理30天前的日志记录

记录一下，希望对有需要的朋友也起一点提示

---