MySQL：如何对MySQL进行压力测试

最新推荐文章于 2024-04-23 16:12:41 发布

OceanStar的学习笔记

最新推荐文章于 2024-04-23 16:12:41 发布

阅读量1.2k

点赞数 2

分类专栏：数据库文章标签： mysql 数据库压力测试

本文链接：https://blog.csdn.net/zhizhengguan/article/details/87867412

版权

数据库专栏收录该内容

289 篇文章 17 订阅

订阅专栏

环境：mysql8.0

基准测试简介

1、什么是基准测试

数据库的基准测试是对数据库的性能指标进行定量的、可复现的、可对比的测试。

基准测试与压力测试

基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑，更加简单、直接、易于测试，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑(如购物车业务)，要求真实的数据。

2、基准测试的作用

对于多数Web应用，整个系统的瓶颈在于数据库；原因很简单：Web应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括CPU、内存、硬盘灯、连接数等）、缓存，都很容易通过水平的扩展（俗称加机器）来实现性能的提高。而对于MySQL，由于数据一致性的要求，无法通过增加机器来分散向数据库写数据带来的压力；虽然可以通过前置缓存（Redis等）、读写分离、分库分表来减轻压力，但是与系统其它组件的水平扩展相比，受到了太多的限制。

而对数据库的基准测试的作用，就是分析在当前的配置下（包括硬件配置、OS、数据库设置等），数据库的性能表现，从而找出MySQL的性能阈值，并根据实际系统的要求调整配置。

3、基准测试的指标

常见的数据库指标包括：

TPS/QPS：衡量吞吐量。
- QPS（Query Per Second）：一次请求就是一条SQL语句，也就是说这个数据库每秒可以处理多少个SQL语句。
- TPS（ransaction Per Second）：TPS往往指的是一个数据库每秒里有多少个事务执行完毕了，事务提交或者回滚都算是事务执行完毕了，所以TPS衡量的是一个数据库每秒处理完的事务的数量
响应时间：包括平均响应时间、最小响应时间、最大响应时间、时间百分比等，其中时间百分比参考意义较大，如前95%的请求的最大响应时间。。
并发量：同时处理的查询请求的数量。

IO相关的压测性能指标

压测是一般还需要关注的一些IO相关的指标如下：

（1）IOPS：这个是指随机IO并发处理的能力。

比如机器可以达到200 IOPS，意识是说每秒可以执行200个随机IO读写请求
这个指标是很关键的。因为在内存（Buffer Pool）中更新的脏数据，最后都会由后台IO线程在不确定的时间，刷回到磁盘里去，这就是随机IO的过程。如果是IOPS指标太低了，就会导致内存里的脏数据刷回磁盘的效率不高

（2）吞吐量：这个是指机器的磁盘存储每秒可以读写多少字节的数据量

这个指标也很关键，我们平时在执行各种SQL语句的时候，提交事务的时候，其实都是大量的写redo log之类的日志的，这些日志都会直接写磁盘文件
所以一条机器每秒可以读写多少字节的数据量，就决定了每秒可以把多少redo log之类的日志写入到磁盘中去。一般来说，我们写redo log之类的日志，都是对磁盘文件进行顺序写入的，不会进行随机读写，而一般普通磁盘的顺序写入的吞吐量每秒可以达到200MB左右
所以通常而言，机器的磁盘吞吐量都是足够承载高并发请求的

（3）latency：这个指标说的是往磁盘写入一条数据的延迟

这个指标也很重要，因为我们执行SQL语句和提交事务的时候，都需要顺序写redo log磁盘文件，所以此时你写一条日志到磁盘文件里去，到底是延迟1ms，还是延迟100us，都会对数据库的SQL执行性能有影响
一般来说，磁盘读写延迟越低，数据库性能越高，执行每个SQL语句和事务的时候速度就越快

除了上面说的QPS、TPS、IOPS、吞吐量、latency这些指标之外，在压测的时候还需要关注机器的其他一些性能指标。

CPU负载：CPU负载是一个很重要的性能指标，因为假设你数据库压测到了每秒处理3000请求了，可能其他的性能指标都还正常，但是此时CPU负载特别高，那么也就说明了你的数据库不能继续往下压测更高的QPS了，否则CPU是吃不消的
网络负载：这个主要是看你的机器带宽下，在压测到一定的QPS和TSP的时候，每秒钟机器的网卡会输入多少MB数据，会输出多少MB数据。因为有可能你的网络带宽最多每秒传输100MB的数据，那么可能你的QPS到1000的时候，网卡就打满了，已经每秒传输100MB的数据了，此时即使其他指标都还算正常，但是你也不能继续压测下去了
内存负载：这个就是看压测到一定情况的时候，你的机器内存消耗了多少，如果说机器内存消耗过高了，就不能继续压测下去了

问题

如果一个交易系统拆分为了很多服务，那么每个服务每秒接收的并发请求是QPS还是TPS呢？

这个明显是QPS，因为每个服务就负责干自己的一些事儿，其实对他来说，每秒并发请求数量就是QPS。

那么对于多个服务组成的一个大的交易系统而言，这个交易系统每秒可以完成多少笔交易，这是QPS还是TPS呢？

其实这个你可以认为是TPS的概念，因为一笔交易需要调用多个服务来完成，所以一笔交易的完成其实就类似数据库里的一个
事务，他涵盖了很多服务的请求调用，所以每秒完成多少笔交易，你可以用TPS来形容。

比如你说交易系统的TPS是300，就是说每秒可以完成300笔交易。那么比如交易系统中的服务A的QPS是500，就是交易系统
中的一个服务A每秒可以处理500个请求。

(root@localhost) [(none)]> show global status like '%question%'; 
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 4     |
+---------------+-------+
1 row in set (0.04 sec)

(root@localhost) [(none)]> show global status like '%uptime%';  --服务器启动到现在的结果
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Uptime                    | 47    |
| Uptime_since_flush_status | 47    |
+---------------------------+-------+
2 rows in set (0.00 sec)

(root@localhost) [(none)]> status
--------------
mysql  Ver 8.0.15 for linux-glibc2.12 on x86_64 (MySQL Community Server - GPL)

Connection id:		8
Current database:	
Current user:		root@localhost
SSL:			Cipher in use is DHE-RSA-AES128-GCM-SHA256
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		8.0.15 MySQL Community Server - GPL
Protocol version:	10
Connection:		localhost via TCP/IP
Server characterset:	utf8mb4
Db     characterset:	utf8mb4
Client characterset:	utf8mb4
Conn.  characterset:	utf8mb4
TCP port:		3306
Uptime:			2 min 14 sec

Threads: 2  Questions: 9  Slow queries: 0  Opens: 126  Flush tables: 2  Open tables: 102  Queries per second avg: 0.067
--------------

4、基准测试的分类

对MySQL的基准测试，有如下两种思路：

（1）针对整个系统的基准测试：通过http请求进行测试，如通过浏览器、APP或postman等测试工具。该方案的优点是能够更好的针对整个系统，测试结果更加准确；缺点是设计复杂实现困难。
（2）只针对MySQL的基准测试：优点和缺点与针对整个系统的测试恰好相反。

在针对MySQL进行基准测试时，一般使用专门的工具进行，例如mysqlslap、sysbench等。其中，sysbench比mysqlslap更通用、更强大，且更适合Innodb（因为模拟了许多Innodb的IO特性），下面介绍使用sysbench进行基准测试的方法。

sysbench

1、sysbench简介

sysbench支持以下几种测试模式：

1、CPU运算性能
2、磁盘IO性能
3、调度程序性能
4、内存分配及传输速度
5、POSIX线程性能
6、数据库性能(OLTP基准测试)

2、sysbench安装

如果你要进行数据库的压测，就是直接使用sysbench工具就可以了

这个工具可以自动帮你在数据库里构造出来大量的数据，你想要多少数据，他就自动给你构造出来多少条数据。
然后这个工具接着可以模拟几千个线程并发的访问你的数据库，模拟使用各种各样的SQL语句来访问你的数据库，包括模拟出来各种事务提交到你的数据库里去，甚至可以模拟出几十万的TPS去压测你的数据库。

apt-get安装

ubuntu18.04

$ sudo apt-get install sysbench

centos

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
sudo yum -y install sysbench
sysbench --version

git 安装

1、下载

$ git clone "https://github.com/akopytov/sysbench"
$ cd sysbench/
$ ls
autogen.sh  ChangeLog  config  configure.ac  COPYING  debian  install-sh  m4  Makefile.am  missing  mkinstalldirs  README.md  rpm  scripts  snap  src  tests  third_party
$ cat README.md

2、安装依赖

$ sudo apt -y install make automake libtool pkg-config libaio-dev 
$ sudo apt -y install libmysqlclient-dev libssl-dev

3、安装sysbench

$ ./autogen.sh 
-- 如果mysql不是安装在默认路径下，那么需要配置
$ ./configure  --prefix=/home/ocean/workspace/mysql/sysbench/install  --with-mysql-includes=/usr/local/mysql/include --with-mysql-libs=/usr/local/mysql/lib --with-mysql       
#--prefix=/usr/sysbench/                    # 指定sysbench的安装目录。
#--with-mysql-includes=/usr/include/mysql/  # 指定安装mysql时候的includes目录。
#--with-mysql-libs=/usr/lib/mysql/          # 指定装mysql时候的lib目录。
# --with-mysql                               #sysbench默认支持mysql，如果需要测试oracle或者pgsql则需要制定–with-oracle或者–with-pgsql。 
$ sudo make -j4
$ sudo make install 
$ export PATH=$PATH:/home/ocean/workspace/mysql/sysbench/install/bin # 注意，如果prefix手动指定了sysbench的安装目录，请添加环境变量

4、测试是否安装成功

$ sysbench --version
sysbench: error while loading shared libraries: libmysqlclient.so.21: cannot open shared object file: No such file or directory
$ locate libmysqlclient.so.21
/usr/local/mysql/lib/libmysqlclient.so.21
$ sudo gedit /etc/ld.so.conf
/usr/local/mysql/lib   --保存退出
$ sudo ldconfig
$ sysbench --version
sysbench 1.1.0-18a9f86

3、sysbench语法

查看 sysbench 的可用命令、选项及內建测试类型的帮助信息

$  sysbench --help
Usage:
  sysbench [options]... [testname] [command]

testname

[testname] 是内置测试的可选名称( 比如。 fileio，memory，cpu，等等 ) 或者一个绑定的Lua脚本的名称( 比如。 oltp_read_only )，或者是特定于自定义的Lua脚本的路径。如果没有在命令行 ( 因此，没有命令，因为在这种情况下，它将被解析为一个 testname ) 上指定测试名，或者者测试名称是一个错误的(" -")，则on会在它的标准输入中执行。

command

[command] 是一个可选参数，它将由sysbench传递给用testname指定的测试或者脚本。命令定义动作必须由测试执行。可用命令的列表取决于特定的测试。一些测试还实现了自己的定制命令。

* 下面是典型测试命令的说明及其用途：
     * prepare:测试前准备工作，比如 为 fileio 测试创建必要的文件，或者者填充数据库测试数据库。
     * run: 正式测试。
     * cleanup: 测试后删掉测试数据 
     * help: 显示使用 testname 参数指定的测试的用法信息。 这包括测试提供的完整命令列表，因此应该使用它来获取可用命令。

options

[options] 是从 ‘–’ 开始的零或者更多命令行选项的列表。
sysbench的参数有很多，其中比较常用的包括：

	> * --threads：客户端的并发连接数，默认 1 个
	> * --events	=N请求总数的限制。 0 ( 默认值) 表示无限制	 
	> * --time：测试执行的时间，单位是秒，该值不要太短，可以选择120, 0表示无限制	，默认10.
	> * oltp-test-mode：执行模式，包括simple、nontrx和complex，默认是complex。simple模式下只测试简单的查询；nontrx不仅测试查询，还测试插入更新等，但是不使用事务；complex模式下测试最全面，会测试增删改查，而且会使用事务。可以根据自己的需要选择测试模式。
	> * oltp-tables-count：测试的表数量，根据实际情况选择
	> * oltp-table-size：测试的表的大小，根据实际情况选择
	> * report-interval：生成报告的时间间隔，单位是秒，如10
    > * debug[=on|off]    是否打印更多调试信息。默认是off
    > * help[=on|off]：是否打印帮助信息。 [off]
    > * version[=on|off] ：是否打印 版本信息。[off]
    > * validate[=on|off]  ：在可能情况下执行验证检查。默认是off。
 
    > * forced-shutdown=STRING ：   在 --time 时间限制到达后，强制关闭之前等待的秒数，默认“off”禁用 
    > *  thread-stack-size=SIZE    ：每个线程的堆栈大小。默认是[64K]
    > * report-interval=N：以秒为单位定期报告中间统计信息。 注意，这里选项生成的统计信息是间隔而不是累积的。 0禁用中间报告

4、sysbench测试注意事项与建议

注意事项

（1）尽量不要在MySQL服务器运行的机器上进行测试，一方面可能无法体现网络（哪怕是局域网）的影响，另一方面，sysbench的运行（尤其是设置的并发数较高时）会影响MySQL服务器的表现。

（2）可以逐步增加客户端的并发连接数（–thread参数），观察在连接数不同情况下，MySQL服务器的表现；如分别设置为10,20,50,100等。

（3）一般执行模式选择complex即可，如果需要特别测试服务器只读性能，或不使用事务时的性能，可以选择simple模式或nontrx模式。

（4）如果连续进行多次测试，注意确保之前测试的数据已经被清理干净。

使用建议

（1）在开始测试之前，应该首先明确：应采用针对整个系统的基准测试，还是针对MySQL的基准测试，还是二者都需要。

（2）如果需要针对MySQL的基准测试，那么还需要明确精度方面的要求：是否需要使用生产环境的真实数据，还是使用工具生成也可以；前者实施起来更加繁琐。如果要使用真实数据，尽量使用全部数据，而不是部分数据。

（3）基准测试要进行多次才有意义。

（4）测试时需要注意主从同步的状态。

（5）测试必须模拟多线程的情况，单线程情况不但无法模拟真实的效率，也无法模拟阻塞甚至死锁情况。

5、sysbench使用例子

测试时间建议2-4小时

性能(CPU)测试

测试计算素数对这个数字除以 2 到这个数字平方根之间的所有数字来验证素数）直到某个最大值所需要的时间
CPU 基准测试时可以指定线程数量和素数上限。性能测试【找范围内最大素数{时间越短越好}】

$ sysbench  cpu help
--cpu-max-prime=N  最大质数发生器数量。默认是10000

--threads
$ sysbench cpu --cpu-max-prime=10000 --report-interval=1 run   -- cpu到底20000时所需要的时间
 Running the test with following options:
Number of threads: 1           -- 线程数，一般指定为CPU核数就可以,比如 --threads=2 
Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1355.07   -- 每一秒事件数

Throughput:
    events/s (eps):                      1355.0670
    time elapsed:                        10.0002s      -- 所有时间 【越小越优秀】
    total number of events:              13551    -- 全部事件数量

Latency (ms):   --等待事件
         min:                                    0.69
         avg:                                    0.74
         max:                                    3.79
         95th percentile:                        0.84   -- 前95%的请求的最大响应时间
         sum:                                 9991.89

Threads fairness:
    events (avg/stddev):           13551.0000/0.00
    execution time (avg/stddev):   9.9919/0.00

$ sysbench cpu  --threads=2  --cpu-max-prime=20000  --report-interval=1  run

线程(thread)测试

测试线程调度器的性能。对于高负载情况下测试线程调度器的行为非常有用。
多核性能，线程调度线程并发执行，循环响应信号量花费的时间
线程调度【线程并发执行，循环响应信号量花费的时间{越少越好}】

$ sysbench  threads help

sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

threads options:
  --thread-yields=N   每个请求产生多少个线程。默认是1000
  --thread-locks=N    每个线程的锁的数量。默认是8

$  sysbench threads --threads=2 --report-interval=1  run

互斥锁(mutex)测试

并发线程同时申请互斥锁循环一定次数花费的时间测试互斥锁的性能
方式是模拟所有线程在同一时刻并发运行，并都短暂请求互斥锁。
互斥锁【并发线程同时申请互斥锁循环一定次数花费的时间{越少越好}】

$ sysbench mutex help
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

mutex options:
  --mutex-num=N   total size of mutex array [4096]
  --mutex-locks=N number of mutex locks to do per thread [50000]
  --mutex-loops=N number of empty loops to do outside mutex lock [10000]

sysbench mutex --threads=2 --mutex-locks=1000000  --report-interval=1  run

内存(memory)测试

以不同块大小传输一定数量的数据,测试内存读写性能
内存【以不同块大小传输一定数量的数据吞吐量大小{越大越好}】

$ sysbench  memory help
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

memory options:
  --memory-block-size=SIZE  测试时内存块大小。默认是1K
  --memory-total-size=SIZE    传输数据的总大小。默认是100G
  --memory-scope=STRING    内存访问范围{global,local}。默认是global
  --memory-hugetlb=[on|off]  从HugeTLB池内存分配。默认是off
  --memory-oper=STRING     内存操作类型。{read, write, none} 默认是write
  --memory-access-mode=STRING存储器存取方式{seq,rnd} 默认是seq

sysbench memory --memory-block-size=8K --memory-total-size=1G  --threads=16 run

文件IO(fileio)测试

测试系统在不同IO负载下的IOPS性能，IO【不同场景下IOPS{越大越好}

# sysbench  fileio help
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

fileio options:
  --file-num=N                   创建测试文件的数量。默认是128
  --file-block-size=N           测试时文件块的大小。默认是16384(16K)  【InnoDB存储引擎页大小，默认为16384。】
  --file-total-size=SIZE        测试文件的总大小。默认是2G
  --file-test-mode=STRING       文件测试模式{seqwr(顺序写), seqrewr(顺序读写), seqrd(顺序读), rndrd(随机读), rndwr(随机写), rndrw(随机读写)}
  --file-io-mode=STRING         文件操作模式{sync(同步),async(异步),mmap(map映射)}。默认是sync
  --file-async-backlog=N        number of asynchronous operatons to queue per thread [128]
  --file-extra-flags=[LIST,...]  使用额外的标志来打开文件{sync,dsync,direct} 。默认为空
  --file-fsync-freq=N           执行fsync()【同步磁盘文件】的频率。(0 – 不使用fsync())。默认是100
  --file-fsync-all[=on|off]     每执行完一次写操作，就执行一次fsync，默认未off。
  --file-fsync-end[=on|off]     在测试结束时才执行fsync。默认是on
  --file-fsync-mode=STRING      使用哪种方法进行同步{fsync, fdatasync}。默认是fsync，不建议fdatasync
  --file-merged-requests=N       尽可能合并最多的IO请求数(0 – 表示不合并)。默认是0
  --file-rw-ratio=N            测试时的读写比例。默认是1.5

使用 fileio 时，需要创建一组测试文件，测试文件需要大于可用内存的大小，避免文件缓存在内存中影响结果。测试流程为：准备测试文件-》测试-》回收测试文件，命令如下：

准备数据

 $ sysbench fileio \
--file-num=4 \
--file-total-size=2G \
prepare

开始测试

$  sysbench fileio --time=300 --report-interval=1 --threads=8 \
	--events=100000000 \
	--file-num=4 \
	--file-total-size=2G \
	--file-block-size=16384 \
	--file-test-mode=rndrw \
	--file-io-mode=sync \
	run
 #time最大测试时间180，即使180内不能完成，也结束测试
 #events最大随机数请求是100000000次
 # 生成的数据文件至少要比内存大，如果文件中的数据能够完全放入内存中，则OS缓存大部分的数据，导致测试结果无法体现IO密集型的工作负载
$  sysbench fileio --time=300 --report-interval=1 --threads=128 --events=100000000 --file-num=4 --file-total-size=2G --file-block-size=16384 --file-test-mode=rndrw --file-extra-flags=direct --file-fsync-freq=1 run

sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

[ 1s ] reads: 4.56 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 142.387

Throughput:   // # 吞吐量
         read:  IOPS=160.70 2.51 MiB/s (2.63 MB/s)    //读磁盘IOPS
         write: IOPS=107.13 1.67 MiB/s (1.76 MB/s)    //写磁盘的带宽
         fsync: IOPS=10.81

Latency (ms):
         min:                                  0.00
         avg:                                 28.64
         max:                               3686.64
         95th percentile:                    200.47
         sum:                            2401434.45

清除数据

$ sysbench --file-total-size=2G --file-num=4 fileio cleanup

MYSQL基准测试应该怎么做（版本二）

测试计划

（1）第一步是按照MySQL和sysbench

（2）接着我们需要在自己的数据库里创建好一个测试库：

我们可以取个名字叫做test_db，同时创建好对应的测试账号，可以叫做test_user，密码也是test_user，让这个用户有权限可以访问test_db。
然后我们将要基于sysbench构建20个测试表，每个表里有100万条数据，接着使用10个并发线程去对这个数据库发起访问，连续访问5分钟，也就是300秒，然后对其进行压力测试。

（3）基于sysbench构造测试表和测试数据

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_read_write --db-ps-mode=disable prepare

上面我们构造了一个sysbench命令，给他加入了很多的参数：

--db-driver=mysql：这个很简单，就是说他基于mysql的驱动去连接mysql数据库，你要是oracle，或者sqlserver，那自然就是其他的数据库的驱动了
--time=300：这个就是说连续访问300秒
--threads=10：这个就是说用10个线程模拟并发访问
--report-interval=1：这个就是说每隔1秒输出一下压测情况
--mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=test_user --mysql-password=test_user：这一大串，就是说连接到哪台机器的哪个端口上的MySQL库，他的用户名和密码是什么
--mysql-db=test_db --tables=20 --table_size=1000000：这一串的意思，就是说在test_db这个库里，构造20个测试表，每个测试表里构造100万条测试数据，测试表的名字会是类似于sbtest1，sbtest2这个样子的
oltp_read_write：这个就是说，执行oltp数据库的读写测试
--db-ps-mode=disable：这个就是禁止ps模式
最后有一个prepare，意思是参照这个命令的设置去构造出来我们需要的数据库里的数据，他会自动创建20个测试表，每个表里创建100万条测试数据，所以这个工具是非常的方便的。

（4）对数据库进行360度的全方位测试
测试数据库的综合读写TPS，使用的是oltp_read_write模式（大家看命令中最后不是prepare，是run了，就是运行压测）：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_read_write --db-ps-mode=disable run

测试数据库的只读性能，使用的是oltp_read_only模式（大家看命令中的oltp_read_write已经变为oltp_read_only了）：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_read_only --db-ps-mode=disable run

测试数据库的删除性能，使用的是oltp_delete模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --table_size=1000000 oltp_delete --db-ps-mode=disable run

测试数据库的更新索引字段的性能，使用的是oltp_update_index模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_update_index --db-ps-mode=disable run

测试数据库的更新非索引字段的性能，使用的是oltp_update_non_index模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_update_non_index --db-ps-mode=disable run

测试数据库的更新非索引字段的性能，使用的是oltp_update_non_index模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_update_non_index --db-ps-mode=disable run

测试数据库的插入性能，使用的是oltp_insert模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_insert --db-ps-mode=disable run

测试数据库的写入性能，使用的是oltp_write_only模式：

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_write_only --db-ps-mode=disable run

使用上面的命令，sysbench工具会根据你的指令构造出各种各样的SQL语句去更新或者查询你的20张测试表里的数据，同时监测出你的数据库的压测性能指标，最后完成压测之后，可以执行下面的cleanup命令，清理数据。

sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=127.0.0.1 --mysqlport=3306 --mysql-user=test_user --mysql-password=test_user --mysql-db=test_db --tables=20 --
table_size=1000000 oltp_read_write --db-ps-mode=disable cleanup

（5）压测结果分析
按照我们上面的命令，我们是让他每隔1秒都会输出一次压测报告的，此时他每隔一秒会输出类似下面的一段东西：

[ 22s ] thds: 10 tps: 380.99 qps: 7312.66 (r/w/o: 5132.99/1155.86/1321.35) lat (ms, 95%): 21.33 err/s: 0.00 reconn/s:
0.00

thds: 10，这个意思就是有10个线程在压测
tps: 380.99，这个意思就是每秒执行了380.99个事务
qps: 7610.20，这个意思就是每秒可以执行7610.20个请求
(r/w/o: 5132.99/1155.86/1321.35)，这个意思就是说，在每秒7610.20个请求中，有5132.99个请求是读请求，1155.86个请求是写请求，1321.35个请求是其他的请求，就是对QPS进行了拆解
lat (ms, 95%): 21.33，这个意思就是说，95%的请求的延迟都在21.33毫秒以下
err/s: 0.00 reconn/s: 0.00，这两个的意思就是说，每秒有0个请求是失败的，发生了0次网络重连

另外在完成压测之后，最后会显示一个总的压测报告：

SQL statistics:
	queries performed:
		read: 1480084 // 这就是说在300s的压测期间执行了148万多次的读请求
		write: 298457 // 这是说在压测期间执行了29万多次的写请求
		other: 325436 // 这是说在压测期间执行了30万多次的其他请求
		total: 2103977 // 这是说一共执行了210万多次的请求
	// 这是说一共执行了10万多个事务，每秒执行350多个事务
	transactions: 105180( 350.6 per sec. )
	// 这是说一共执行了210万多次的请求，每秒执行7000+请求
	queries: 2103977 ( 7013.26 per sec. )
	ignored errors: 0 (0.00 per sec.)
	reconnects: 0 (0.00 per sec.)
// 下面就是说，一共执行了300s的压测，执行了10万+的事务
General staticstics:
	total time: 300.0052s
	total number of events: 105180
Latency (ms):
	min: 4.32 // 请求中延迟最小的是4.32ms
	avg: 13.42 // 所有请求平均延迟是13.42ms
	max: 45.56 // 延迟最大的请求是45.56ms
	95th percentile: 21.33 // 95%的请求延迟都在21.33ms以内

除了QPS和TPS以外，我们还需要观察机器的性能

根据上面结果，我们就可以看到自己的数据库能抗下多少QPS和TSP了。

上面我们是用了10个线程去进行压测，但是如果你的机器性能很好，还可以在sysbench中不停的增加线程的数据，比如使用20个线程，甚至100个线程去并发的访问数据库，直到发现数据库的QPS和TPS上不去了。

当然，这个不停的提高线程数量，不停地让数据库承载更高的QPS的过程，还需要配合我们对机器性能表现的观察来做，不能盲目的不停的增加线程去压测数据库

那在压测过程中，如何同时观察机器的性能表现，从而来决定是否要继续增加线程数量去压测数据库呢

为什么在不停增加线程数量的时候，要密切关注机器性能？

举个例子。

首先，假设数据库当前抗下了每秒2000的QPS，同时这个时候机器的CPU负载、内存负载、网络负载、磁盘IO负载，都在正常的范围内，负载相对较高一些，但是还没有达到这些硬件的极限，那么我们可以认为这台数据库在高峰期抗到每秒2000的QPS，是没有问题的。

但是如果你一直不停的在压测过程中增加sysbench的线程数量，然后数据库此时勉强抗到了每秒5000的QPS了，但是这个时候你发现机器的CPU已经满负荷运行了，内存使用率特别高，内存都快要不够了，然后网络带宽几乎被打满了，磁盘IO的等待时间特别长，这个时候说明机器已经到了极致了，再搞下去，机器都快挂了。

所以这个时候你压测出来的5000 QPS是没什么代表性的，因为在生产环境根本不可能让数据库抗下这么高的QPS，因为到这么高的QPS就说明你的数据库几乎已经快要挂掉了，这是不现实的。

所以说，在压测的过程中，必须是不停的增加sysbench的线程数量，持续的让数据库承载更高的QPS，同时密切关注机器的CPU、内存、磁盘和网络的负载情况，在硬件负载情况比较正常的范围内，哪怕负载相对较高一些，也还是可以继续增加线程数量和提高数据库的QPS的。

然后当你不停的增加线程数量，发现在数据库抗下一个QPS的数值的同时，机器的CPU、内存、网络和磁盘的负载已经比较高了，到了一个有一定风险的临界值的了，此时就不能继续增加线程数量和提高数据库抗下的QPS了。

在硬件的一定合理的负载范围内，把数据库的QPS提高到最大，这就是数据库压测的时候最合理的一个极限QPS值

压测时如何观察机器的CPU负载情况？

直接在linux命令行只能够输入top指令就可以了。

首先我们会看到如下一行信息：

top - 15:52:00 up 42:35, 1 user, load average: 0.15, 0.05, 0.01

这行信息是最直观可以看到机器的cpu负载情况的，首先15:52:00指的是当前时间，up 42:35指的是机器已经运行了多长时间，1 user就是说当前机器有1个用户在使用。

最重要的是load average: 0.15, 0.05, 0.01这行信息，他说的是CPU在1分钟、5分钟、15分钟内的负载情况。

这里要给大家着重解释一下这个CPU负载是什么意思：

假设我们是一个4核的CPU，此时如果你的CPU负载是0.15，这就说明，4核CPU中连一个核都没用满，4核CPU基本都很空闲，没啥人在用。
如果你的CPU负载是1，那说明4核CPU中有一个核已经被使用的比较繁忙了，另外3个核还是比较空闲一些。要是CPU负载是1.5，说明有一个核被使用繁忙，另外一个核也在使用，但是没那么繁忙，还有2个核可能还是空闲的。
如果你的CPU负载是4，那说明4核CPU都被跑满了，如果你的CPU负载是6，那说明4核CPU被繁忙的使用还不够处理当前的任务，很多进程可能一直在等待CPU去执行自己的任务。

这个就是CPU负载的概念和含义。

上面都是0.15之类的，说明CPU根本就没怎么用。

但是如果你在压测的过程中，发现4核CPU的load average已经基本达到3.5，4了，那么说明几个CPU基本都跑满了，在满负荷运转，那么此时你就不要再继续提高线程的数量和增加数据库的QPS了，否则CPU负载太高是不合理的。

压测时如何观察机器的内存负载情况？

在你执行top命令之后，中间我们跳过几行内容，可以看到如下一行内容：

Mem: 33554432k total, 20971520k used, 12268339 free, 307200k buffers

这里说的就是当前机器的内存使用情况，这个其实很简单，明显可以看出来就是总内存大概有32GB，已经使用了20GB左右的内存，还有10多G的内存是空闲的，然后有大概300MB左右的内存用作OS内核的缓冲区了。

对于内存而言，同样是要在压测的过程中紧密的观察，一般来说，如果内存的使用率在80%以内，基本都还能接受，在正常范围内，但是如果你的机器的内存使用率到了70%~80%了，就说明有点危险了，此时就不要继续增加压测的线程数量和QPS了，差不多就可以了。

压测时如何观察机器的磁盘IO情况？

$ dstat -d
-dsk/total-
 read  writ
 103k  211k
 0     11k

上面可以清晰的看到，存储的IO吞吐量是每秒钟读取103KB的数据，每秒写入211KB的数据，像这个存储IO吞吐量基本上都不算多的，因为普通的机械硬盘都可以做到每秒钟上百MB的读写数据量。

$ dstat -r
--io/totalread writ
0.25 31.9
 0 253
 0 39.0

上面可以看到读IOPS和写IOPS分别是多少，也就是随机磁盘读取每秒钟多少次，随机磁盘写入每秒钟执行多少次。一般来说，随机磁盘读写每秒在两三百次都是可以承受的。

所以在这里，我们就需要在压测的时候密切观察机器的磁盘IO情况，如果磁盘IO吞吐量已经太高了，都达到极限的每秒上百MB了，或者随机磁盘读写每秒都到极限的两三百次了，此时就不要继续增加线程数量了，否则磁盘IO负载就太高了。

压测时观察网卡的流量情况

$ dstat -n
-net/total
recv send
16k 17k

这个就是说每秒钟网卡接收到流量有多少kb，每秒钟通过网卡发送出去的流量有多少kb，通常来说，如果你的机器使用的是千兆网卡，那么每秒中网卡的总流量也就在100MB左右，甚至更低一些。

所以我们周期压测的时候也需要观察号网卡的流量情况，如果网卡传输流量已经到了极限值了，那么此时你再怎么提高sysbench线程数量，数据库的QPS页上不去了，因为这台机器无法通过网卡传输更多的数据了

MYSQL性能(oltp)测试（版本一）

通过一系列LUA脚本来替换之前的oltp，来模拟更接近真实的基准测试环境。这些测试脚本包含：

$ cd /home/ocean/workspace/mysql/sysbench/install/share/sysbench
$ ls
bulk_insert.lua  oltp_insert.lua        oltp_read_write.lua        oltp_write_only.lua       tests
oltp_common.lua  oltp_point_select.lua  oltp_update_index.lua      select_random_points.lua
oltp_delete.lua  oltp_read_only.lua     oltp_update_non_index.lua  select_random_ranges.lua

各脚本使用方式基本类似。
备注：oltp_common.lua，它是一个通用脚本，是被其它lua脚本调用的，它不能直接拿来测试。

数据库准备

创建测试数据库

(root@localhost) [(none)]> create database sbtest;

开始测试

准备数据

$ sysbench /home/ocean/workspace/mysql/sysbench/install/share/sysbench/oltp_read_only.lua \
--mysql-host=127.0.0.1 \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password='123456' \
--mysql-db=sbtest \
--db-driver=mysql \
--tables=10 \
--table-size=1000000 \
--report-interval=10 \
--threads=128 \
--time=120 \
prepare

备注：如果你登陆到mysql，然后查看sbtest中的数据，可以发现sbtest中生成了10个表，每隔表中1000000条数据。

(root@localhost) [sbtest]> show tables;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1          |
| sbtest10         |
| sbtest2          |
| sbtest3          |
| sbtest4          |
| sbtest5          |
| sbtest6          |
| sbtest7          |
| sbtest8          |
| sbtest9          |
+------------------+
10 rows in set (0.00 sec)

(root@localhost) [sbtest]> desc sbtest1;
+-------+-----------+------+-----+---------+----------------+
| Field | Type      | Null | Key | Default | Extra          |
+-------+-----------+------+-----+---------+----------------+
| id    | int(11)   | NO   | PRI | NULL    | auto_increment |
| k     | int(11)   | NO   | MUL | 0       |                |
| c     | char(120) | NO   |     |         |                |
| pad   | char(60)  | NO   |     |         |                |
+-------+-----------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

(root@localhost) [sbtest]> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
|  1000000 |
+----------+
1 row in set (0.10 sec)

(root@localhost) [sbtest]> select count(1) from sbtest2;
+----------+
| count(1) |
+----------+
|  1000000 |
+----------+

开始测试

$ sysbench /home/ocean/workspace/mysql/sysbench/install/share/sysbench/oltp_read_only.lua \
--mysql-host=127.0.0.1 \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password='123456' \
--mysql-db=sbtest \
--db-driver=mysql \
--tables=10 \
--table-size=1000000 \
--report-interval=10 \
--threads=128 \  
--time=120 \
run

测试结果【虚拟机上测试】

sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)

####以下是每10秒返回一次的结果，统计的指标包括：
#### 线程数、tps(每秒事务数)、qps(每秒查询数)、
#### 每秒的读/写/其它次数、延迟、每秒错误数、每秒重连次数
[ 10s ] thds: 128 tps: 511.55 qps: 8296.37 (r/w/o: 7260.48/0.00/1035.90) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 128 tps: 435.30 qps: 6972.67 (r/w/o: 6102.06/0.00/870.61) lat (ms,95%): 1903.57 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            1262338     //总select数量;
        write:                           0                 //总update、insert、delete语句数量【写】；
        other:                           180334       //commit、unlock tables以及其他mutex的数量;
        total:                           1442672      
    transactions:                        90167  (750.66 per sec.)   //TPS;
    queries:                             1442672 (12010.58 per sec.)   //QPS
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

Throughput:
    events/s (eps):                      750.6609
    time elapsed:                        120.1168s    //即time指定的压测实际;
    total number of events:              90167   //总请求数,一般与transactions相同;

Latency (ms):
         min:                                    1.16        //最小响应时间;
         avg:                                  170.44       //平均响应时间;    
         max:                                 9083.11      //最大响应时间;
         95th percentile:                      733.00   //95%的语句的平均响应时间;
         sum:                             15368122.92   //总响应时间;

Threads fairness:
    events (avg/stddev):           704.4297/44.22
    execution time (avg/stddev):   120.0635/0.03

我们一般关注的指标主要有:

response time avg：平均响应时间（后面的95%的大小可以通过–percentile=98的方式去更改）。
transactions：精确的说是这一项后面的TPS，但如果使用了–skip-trx=on，这项事务数为0，需要用total number of events去除以总时间，得到tps（其实还可以分为读tps和写tps）。
queries：用它除以总时间，得到吞吐量QPS。【queries/time elapsed】
当然还有一些系统层面的cpu，io，mem相关指标。

清理数据

sysbench /home/ocean/workspace/mysql/sysbench/install/share/sysbench/oltp_read_only.lua \
--mysql-host=127.0.0.1 \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password='123456' \
--mysql-db=sbtest \
--db-driver=mysql \
--tables=10 \
--table-size=1000000 \
--report-interval=10 \
--threads=128 \
--time=120 \
cleanup

用sysbench轻松定制自己的测试场景

请参考：https://yq.aliyun.com/articles/335621

mysqladmin

1、mysqladmin简介

mysqladmin是一个执行管理操作的客户端程序。它可以用来检查服务器的配置和当前状态、创建和删除数据库等。

官方链接

2、mysqladmin使用

~$  mysqladmin -uroot -p -i 2 -c 5 status --每两秒查看一次服务器的状态，总共重复5次。
Enter password: 
Uptime: 1328  Threads: 2  Questions: 15  Slow queries: 0  Opens: 126  Flush tables: 2  Open tables: 102  Queries per second avg: 0.011
$ mysqladmin -uroot -p status  --查看服务器的状况：status
Enter password: 
Uptime: 1397  Threads: 2  Questions: 21  Slow queries: 0  Opens: 126  Flush tables: 2  Open tables: 102  Queries per second avg: 0.015
$ mysqladmin -u root -p原密码 password 'newpassword' --修改密码
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
$ mysqladmin -uroot -p ping --检查mysqlserver是否可用
$ mysqladmin -uroot -p version --查询服务器的版本
$ mysqladmin -uroot -p extended-status --查看服务器状态的当前值
$ mysqladmin -uroot -p variables  --查询服务器系统变量值
$ mysqladmin -uroot -p processlist  显示服务器所有运行的进程
$ mysqladmin -uroot -p-i 1 processlist        //每秒刷新一次
$ mysqladmin -uroot -p create daba-test  --创建数据库
$ mysqlshow -uroot -p  --显示服务器上的所有数据库
$ mysqlshow -uroot -p daba-test --显示数据库daba-test下有些什么表
$ mysqlshow -uroot -p daba-test -v  --统计daba-test 下数据库表列的汇总
$ mysqlshow -uroot -p daba-test -v -v --统计daba-test 下数据库表的列数和行数
$ mysqladmin -uroot -p drop daba-test  --删除数据库 daba-test
$ mysqladmin -uroot -p reload  --重载权限信息
$ mysqladmin -uroot -p refresh  --刷新所有表缓存，并关闭和打开log
$ mysqladmin -uroot -p shutdown  --使用安全模式关闭数据库
-- 刷新命令mysqladmin flush commands
# mysqladmin -u root -ptmppassword flush-hosts  --清空主机相关的缓存，包括：DNS解析缓存、连接错误次数过多而被拒绝访问mysqld的主机等
# mysqladmin -u root -ptmppassword flush-logs  --关闭日志，打开新日志对二进制、中继日志进行滚动
# mysqladmin -u root -ptmppassword flush-privileges -- 刷新配置
# mysqladmin -u root -ptmppassword flush-status  --重置状态变量
# mysqladmin -u root -ptmppassword flush-tables  --关闭当前打开的表文件句柄
# mysqladmin -u root -ptmppassword flush-threads
--  mysqladmin 执行kill 进程：
# mysqladmin -uroot -p processlist
# mysqladmin -uroot -p kill idnum

-- 停止和启动MySQL replication on a slave server
# mysqladmin -u root -p stop-slave
# mysqladmin -u root -p start-slave

-- 同时执行多个命令
# mysqladmin -u root -p process status version
$ mysqladmin extended-status -uroot -p -r -i 1 | grep -i Question  -- 查看IPS
$ top

vmstat

$ vmstat 5;   --每隔5s打印一个报告
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 483328 218964 130648 723596    1    4    26    50   82  138  2  2 95  0  0
 0  0 483328 218964 130656 723596    0    0     0    10  382  842  0  1 99  0  0
 0  0 483328 218964 130664 723588    0    0     0     6  364  882  0  1 99  0  0

proc：
- r：显示有多少进程正在等待CPU
- b：显示多少进程正在不可以中断地休眠[通常意味它们在等待I/O，例如磁盘，网络，用户输入等等]
memory
- swpd：有多少块被切换出了磁盘[页面交换]
- free ：未被使用地块
- buff ：被用作缓冲地快
- cache：被用作操作系统缓存地块
swap：页面交换
- si：每秒有多少块正在被换入磁盘
- so：每秒有多少块正在被换出磁盘
- si与so为0性能最好，最好不要每秒超过10块，不要有突发性地高峰
io：反映了硬盘IO
- bi：显示有多少块从块设备读取
- bo：显示有多少块从块设备写入
system：
- in：显示每秒中断次数
- cs ：显示每秒上下文切换次数[当OS停止一个化进程转而运行另一个进程时]—》最好不要超过100 000次
cpu：所有的CPU时间花费在各类操作的百分百
- us ：执行用户代码
- sy：执行内核代码—>CPU的利用率，最好不要超过20%
- id：空闲
- wa：等待IO
- st：如果在虚拟机中就有，表示虚拟机想要运行但是系统管理查询转而运行其他的对象的时间。

iostat

$ sudo apt install sysstat
$ iostat -xm 3 # x表示显示扩展统计信息，m表示以兆为单位显示，3表示每隔3秒显示\
Linux 4.18.0-13-generic (ubuntu) 	01/24/2019 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.19    0.02    2.10    0.43    0.00   95.26

Device            r/s     w/s     rMB/s     wMB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
loop0            0.01    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.92    0.00   0.00     1.19     0.00   1.01   0.00
loop1            0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00   27.32    0.00   0.00     2.60     0.00  27.06   0.00
loop2            0.25    0.00      0.00      0.00     0.00     0.00   0.00   0.00    5.52    0.00   0.00     1.04     0.00   0.29   0.01
loop3            0.02    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.30    0.00   0.00     1.12     0.00   0.36   0.00

CPU属性	说明
%user	CPU处在用户模式下的时间百分比
%nice	CPU处在带NICE值的用户模式下的时间百分比
%sys	CPU处在系统模式下的时间百分比
%iowait	CPU等待IO完成时间的百分比
%steal	管理程序维护另一个虚拟处理器时，虚拟CPU的无意的等待时间的百分比
%idle	闲置cpu的百分比

提示：

如果%iowait的值过高，表示硬盘存在I/O瓶颈;
如果%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU* 等待分配内存，此时应加大内存容量。
如果%idle值如果持续很低，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。

Device属性	说明
rrqm/s	每秒进行合并的读操作数目
wrqm/s	每秒进行合并的的写操作数目
r/s	每秒完成的读 I/O 设备次数
w/s	每秒完成的写 I/O 设备次数
rsec/s	每秒读扇区数
wsec/s	每秒写扇区数
rkB/s	每秒读K字节数
wkB/s	每秒写K字节数
avgrq-sz	平均每次设备I/O操作的数据大小 (请求的扇区数)
avgqu-sz	平均I/O队列长度(在设备队列中等待的请求数)
await	平均每次设备I/O操作的等待时间 (毫秒)–>磁盘排队上花费的毫秒数
svctm	平均每次设备I/O操作的服务时间 (毫秒)–>服务请求花费的毫秒数
%util	一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比

设备服务请求的并发数：(r/s+w/s)*(svctm/1000) = (avgqu-sz * svctm)/await
提示：

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；
如果 await 远大于 svctm，说明I/O队列太长，io响应太慢，则需要进行必要优化。
如果avgqu-sz比较大，也表示有当量io在等待。

参考：http://www.ywnds.com/?p=10111
参考：https://blog.csdn.net/kikajack/article/details/79977108
参考：http://www.cnblogs.com/kismetv/p/7615738.html
参考：https://wiki.gentoo.org/wiki/Sysbench
参考：https://blog.csdn.net/joeson7456/article/details/80749149
参考：https://blog.51cto.com/itest/1737682
参考：https://blog.51cto.com/13214087/2140038
参考：https://blog.csdn.net/joeson7456/article/details/80749149#sysbench-%E4%B9%8B-mysql%E8%AF%AD%E6%B3%95
参考：https://www.cnblogs.com/sykblogs/p/9381382.html
参考：<高性能MYSQL>

OceanStar的学习笔记

关注

2
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
MySQL：如何对MySQL进行压力测试

环境：mysql8.0基准测试简介1、什么是基准测试数据库的基准测试是对数据库的性能指标进行定量的、可复现的、可对比的测试。基准测试与压力测试基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑，更加简单、直接、易于测试，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑(如购物车业务)，要求真实的数据。2、基准测试的作用对于多数Web应用，整个系统的瓶颈在于数据库；原因很简单：Web应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括CPU、内存、硬盘
复制链接

扫一扫