MySQL --近真实业务场景性能诊断及优化

最新推荐文章于 2025-06-20 03:16:35 发布

lichx123

最新推荐文章于 2025-06-20 03:16:35 发布

阅读量754

点赞数

CC 4.0 BY-SA版权

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/lichx123/article/details/126596642

本文通过阿里云ECS实例上的MySQL 5.7数据库进行sysbench读写测试，模拟业务环境，并利用sar、vmstat、iostat等工具对CPU、内存、IO进行全面性能诊断，同时借助top和MySQL InnoDB状态报告深入分析数据库性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1 环境描述

这里的环境是一个阿里云ECS的实例，在上面安装了MySQL　５.７　，用sysbench给数据库加压，使用读写测试脚本，模拟真实业务的场景。

ECS是配置比较低的入门级实例，具体的配置见下图：

MySQL数据库安装的是5.7的版本，详细信息如下：

mysql> select version();
    +-----------+
    | version() |
    +-----------+
    | 5.7.34    |
    +-----------+
    1 row in set (0.01 sec)

sysbench这里没有用安装版本，而是用docker来运行，用的映像是下面这个：

[root@ ~]# docker images
    REPOSITORY              TAG       IMAGE ID       CREATED       SIZE
    severalnines/sysbench   latest    0e71335a2211   3 years ago   429MB

准备数据，运行sysbench的prepare的命令准备数据

docker run --rm=true --name=sb-prepare 0e71335a2211 sysbench --test=/usr/share/sysbench/oltp_read_write.lua --mysql-host=172.20.11.244 --mysql-port=3306 --mysql-db=sysbenchdb --mysql-user="u_sysbench"  --mysql-password='123456' --tables=4 --table_size=100000 --threads=2 --time=300 --report-interval=3 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 prepare

这里运行的是oltp_read_write.lua脚本，创建4个表，每个表插入100000行数据。

2 运行sysbench 测试，模拟业务环境

docker run --name=sb-run 0e71335a2211 sysbench --test=/usr/share/sysbench/oltp_read_write.lua --mysql-host=172.20.11.244 --mysql-port=3306 --mysql-db=sysbenchdb --mysql-user="u_sysbench"  --mysql-password=123456 --tables=4 --table_size=100000 --threads=4 --time=2000 --report-interval=10 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 run

为了使测试更接近真实的业务环境，这里运行sysbench的OLTP读写测试，考虑到数据库服务器配置，运行4个线程进行测试，运行的时间使2000秒，每10秒产生一个报告。

上面的命令运行之后，在数据库上产生的负载如下：

[ 1200s ] thds: 4 tps: 159.90 qps: 2876.88 (r/w/o: 2237.29/639.60/0.00) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00
[ 1210s ] thds: 4 tps: 160.20 qps: 2884.51 (r/w/o: 2243.91/640.50/0.10) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00
[ 1220s ] thds: 4 tps: 157.00 qps: 2826.52 (r/w/o: 2198.22/628.30/0.00) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00
[ 1230s ] thds: 4 tps: 160.60 qps: 2890.58 (r/w/o: 2248.39/642.10/0.10) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00
[ 1240s ] thds: 4 tps: 159.00 qps: 2861.80 (r/w/o: 2226.00/635.70/0.10) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00
[ 1250s ] thds: 4 tps: 159.00 qps: 2862.81 (r/w/o: 2226.01/636.80/0.00) lat (ms,95%): 29.72 err/s: 0.00 reconn/s: 0.00
[ 1260s ] thds: 4 tps: 165.00 qps: 2969.59 (r/w/o: 2309.99/659.60/0.00) lat (ms,95%): 29.19 err/s: 0.00 reconn/s: 0.00
[ 1270s ] thds: 4 tps: 156.80 qps: 2821.81 (r/w/o: 2194.60/627.20/0.00) lat (ms,95%): 30.81 err/s: 0.00 reconn/s: 0.00
[ 1280s ] thds: 4 tps: 158.60 qps: 2855.91 (r/w/o: 2221.01/634.80/0.10) lat (ms,95%): 29.19 err/s: 0.00 reconn/s: 0.00
[ 1290s ] thds: 4 tps: 161.10 qps: 2899.57 (r/w/o: 2255.38/644.09/0.10) lat (ms,95%): 29.19 err/s: 0.00 reconn/s: 0.00
[ 1300s ] thds: 4 tps: 153.90 qps: 2769.73 (r/w/o: 2154.45/615.29/0.00) lat (ms,95%): 34.95 err/s: 0.00 reconn/s: 0.00

每秒160个左右的事务，2200多个读操作，600多个写操作，运行2000秒后负载的汇总信息如下：

SQL statistics:
    queries performed:
        read:                            4461870
        write:                           1274667
        other:                           104
        total:                           5736641
    transactions:                        318656 (159.33 per sec.)
    queries:                             5736641 (2868.29 per sec.)
    ignored errors:                      49     (0.02 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          2000.0224s
    total number of events:              318656

Latency (ms):
         min:                                   11.55
         avg:                                   25.10
         max:                                  549.47
         95th percentile:                       30.26
         sum:                              7999234.11

Threads fairness:
    events (avg/stddev):           79664.0000/39.89
    execution time (avg/stddev):   1999.8085/0.00

上面的报告可以看到sql统计信息，通用统计信息，延迟及业务在线程间的分布情况。

从sql统计信息可以看到，这段时间执行的sql 查询的总数，每类查询的数量，事务总数，每秒平均值，查询总数，每秒平均值。

通用统计信息显示的测试执行的总时间和时间的总数。

延迟信息显示了延时的最大值（549ms），最小值（11.55ms）、平均值（25，10ms）和95%的sql的延迟的均值（30.26ms）以及总的延迟时间（7999234.11）。

业务在线程间的分配情况显示了业务在线程之间分配的是否均衡。从输出结果来看，业务在线程间的分配十分均衡，执行时间的偏差为0，事件的偏差才39个。

3 总体性能诊断（linux sar工具）

怎样对数据库这段时间内的总体性能有一个整体的了解，比如对CPU、内存、IO有一个整体的把握，linux操作系统下的sar是一个很好的工具，这个工具可以显示当天的cpu、内存和io的使用信息。先来看一下CPU信息

[root@ ~]# sar -P ALL
Linux 4.18.0-348.7.1.el8_5.x86_64 (iZ2ze0t8khaprrpfvmevjiZ)     08/25/2022      _x86_64_        (1 CPU)

09:20:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:30:00 AM     all      0.76      0.00      1.72      0.05      0.00     97.47
09:30:00 AM       0      0.76      0.00      1.72      0.05      0.00     97.47

09:30:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:40:00 AM     all      3.89      0.00      3.39      2.07      0.00     90.65
09:40:00 AM       0      3.89      0.00      3.39      2.07      0.00     90.65

09:40:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:50:00 AM     all     33.16      0.00     22.55     20.38      0.00     23.90
09:50:00 AM       0     33.16      0.00     22.55     20.38      0.00     23.90

09:50:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:00:00 AM     all     33.55      0.00     22.80     19.99      0.00     23.67
10:00:00 AM       0     33.55      0.00     22.80     19.99      0.00     23.67

10:00:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:10:00 AM     all     33.27      0.00     22.60     20.25      0.00     23.88
10:10:00 AM       0     33.27      0.00     22.60     20.25      0.00     23.88

10:10:00 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:20:00 AM     all      8.82      0.00      6.89      5.29      0.00     79.00
10:20:00 AM       0      8.82      0.00      6.89      5.29      0.00     79.00

从sar命令显示的信息可以看出，这个服务器上只有一个cpu，在我们运行sysbench测试的这段时间内，cpu利用率有明显的上升，iowait也稍微高点，达到了20以上，从这些信息我们可以得到什么结论？一个是CPU的负载比较高，因为cpu的空载率私有23%，另一个是这个服务器在IO上应该存在瓶颈，CPU有大量的时间消耗在IO等待上，不能从分发挥作用。下面看一下这个服务器的io信息

[root@ ~]# sar -d
Linux 4.18.0-348.7.1.el8_5.x86_64 (iZ2ze0t8khaprrpfvmevjiZ)     08/25/2022      _x86_64_        (1 CPU)

12:00:00 AM       DEV       tps     rkB/s     wkB/s   areq-sz    aqu-sz     await     svctm     %util
09:40:00 AM  dev253-0     63.05     85.73   1401.92     23.60      0.11      1.82      1.39      8.75
09:50:00 AM  dev253-0    719.75      0.39   5860.42      8.14      0.96      1.33      1.38     99.35
10:00:00 AM  dev253-0    723.44      1.98   5363.50      7.42      0.95      1.32      1.37     99.42
10:10:00 AM  dev253-0    719.69      0.27   5155.64      7.16      0.95      1.32      1.38     99.45
10:20:00 AM  dev253-0    186.00      0.33   1404.04      7.55      0.25      1.32      1.37     25.45
10:30:00 AM  dev253-0      0.61      3.03      3.09     10.05      0.00      0.96      0.45      0.03

这个服务器只有一个IO设备，tps值高达700多，利用率也达到了99%之上，这台ECS的IO能力还是不错的，如果按照机械盘一个100多的iops值来说，能达到700个tps还是相当可以的，不过，这台服务器的IO几乎已经计划发挥到极限了，到达了瓶颈。

服务器的内存是否充足可以从服务器是否有换页来判断。

[root@ ~]# sar -W
Linux 4.18.0-348.7.1.el8_5.x86_64 (iZ2ze0t8khaprrpfvmevjiZ)     08/25/2022      _x86_64_        (1 CPU)

12:00:00 AM  pswpin/s pswpout/s
09:30:00 AM      0.00      0.00
09:40:00 AM      0.00      0.00
09:50:00 AM      0.00      0.00
10:00:00 AM      0.00      0.00
10:10:00 AM      0.00      0.00
10:20:00 AM      0.00      0.00
10:30:00 AM      0.00      0.00

在运行sysbench测试这个时间段内，没有内存页的换入和换出，服务器在内存方面没有瓶颈。

4 特定时间段的性能诊断

4.1 vmstat持续监控内cpu、内存性能

各个版本的linux都有一个简单使用的cpu、内存性能诊断工具，这个工具就是vmstat，通过这个工具，可以持续监控服务器的cpu、内存的关键性能指标，快速判断服务器当前是否存在性能瓶颈，以及性能瓶颈所在。下面的命令中，第一个参数1是报告的输出间隔（单位是秒），3 是输出报告的次数。

[root@ ~]# vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 9  0      0 316524    500 922444    0    0  1161   106   19   16  2  2 95  1  0
 2  1      0 316464    500 922444    0    0     0  5474 3344 14705 37 20 23 19  0
 0  0      0 316496    500 922444    0    0     0  5358 3336 14675 34 24 24 19  0

这个命令的输出里面包含了很多有用的信息，报告里面的第一行的值是从服务器上一次启动以来的平均值，后面的报告就是这个时间间隔内的平均值了，看当前的性能要从第二行开始看起。procs栏的两列是服务器当前运行过的任务，r是正在运行的队列，b是被阻塞的队列，这台服务器的cpu个数是1，第二行我们可以看到正在运行的队列里有两个任务，被阻塞的队列里有一个任务，至少在这个时间段内，服务器在io和cpu上都可能存在这瓶颈。

内存一栏是内存的使用情况，这了不用关注，要判断服务器是否存在瓶颈，可以从swap一栏进行判断，这里的换入换出都是0，可以认为内存够用。

cpu一栏里面是cpu的使用情况，从这里可以看到cpu的wait较大，达到了23%，而cpu的空闲为19%，这更加确认了cpu和io存在性能瓶颈。io的瓶颈还需要进一步判断，下一节会涉及这个方面的内容。

4.2 iostat监控io性能

iostat也是linux提供的性能诊断工具，用于io方面的诊断，这个工具的使用同vmstat类似，也是两个参数，第一个表示间隔，第二个是次数。

[root@ ~]# iostat 1 3
Linux 4.18.0-348.7.1.el8_5.x86_64 (iZ2ze0t8khaprrpfvmevjiZ)     08/25/2022      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.00    0.00    2.33    0.93    0.00   94.73

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda               9.46      1149.02       107.07  994136267   92640010

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          34.00    0.00   25.00   19.00    0.00   22.00

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda             741.00         0.00      5325.00          0       5325

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.00    0.00   23.00   19.00    0.00   23.00

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda             729.00         0.00      5401.50          0       5401

iostat也提供cpu的性能指标，在这里要关注的是io指标，tps是每秒的io操作，读写操作的单位是块，这里可以看到tps值很高，超过了700，存在io瓶颈。

4.3 top检测MySQL线程的性能

不同与Oracle和postgresql，MySQL采用的是线程模型，适用于高并发简单事务环境，linux操作系统下的ps、pidstat、top都可以用于线程的监控，top工具支持batch模式和交互式模式，是linux操作系统下很好用的性能监控工具，大家经常使用的是交互式模式，batch模式不常用，这里介绍一下，命令及输出如下所示：

[root@ ~]# top -b -n1 -H -p 46748
top - 09:51:26 up 10 days, 13 min,  2 users,  load average: 2.53, 2.30, 1.40
Threads:  32 total,   0 running,  32 sleeping,   0 stopped,   0 zombie
%Cpu(s): 29.4 us, 23.5 sy,  0.0 ni, 23.5 id, 17.6 wa,  0.0 hi,  5.9 si,  0.0 st
MiB Mem :   1816.9 total,    308.9 free,    606.8 used,    901.2 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1170.1 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  46777 mysql     20   0 1167952 338360  22532 S   6.2  18.2   1:09.31 mysqld
  48993 mysql     20   0 1167952 338360  22532 S   6.2  18.2   1:09.27 mysqld
  49091 mysql     20   0 1167952 338360  22532 S   6.2  18.2   1:07.80 mysqld
  49092 mysql     20   0 1167952 338360  22532 D   6.2  18.2   1:07.85 mysqld
  46748 mysql     20   0 1167952 338360  22532 S   0.0  18.2   0:00.27 mysqld
  46749 mysql     20   0 1167952 338360  22532 S   0.0  18.2   0:00.00 mysqld
  46750 mysql     20   0 1167952 338360  22532 S   0.0  18.2   0:00.87 mysqld

上面的命令中，-b选项意指运行在batch模式，如果没有这个选项，top就会运行在交互模式下，-n1 指运行一次，-H显示线程信息，-p 后面的参数是进程id，指定要监控的进程，这里是MySQL后台进程mysqld的进程id，可以通过下面这个命令获得

[root@ ~]# ps -ef|grep mysqld |grep -v grep|grep -v safe
mysql      46748   46649  1 Aug24 ?        00:13:32 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/mysqldata --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=iZ2ze0t8khaprrpfvmevjiZ.err --pid-file=iZ2ze0t8khaprrpfvmevjiZ.pid

命令的输出截取了后面的没有意义的部分，开头部分是汇总信息包括服务器的启动启动时间、负载均值，MySQL的线程总数、不同状态下线程的数量、整个服务器cpu和内存的性能指标。这部分内容之后就是每个线程的cpu、内存性能指标，因为是同一进程下的线程，使用的是相同的内存，所以内存指标意义不大，cpu利用率则是每个线程不同的，这里有四个线程的cpu利用率都是6.2%，sysbench的四个线程负载比较均衡，这个从sysbench的总结报告里已经看到。

4.4 MySQL innodb引擎状态报告--分析数据库性能

InnoDB是MySQL主流版本的默认存储引擎，这个引擎的状态报告提供的信息十分详细，对数据库性能的诊断十分有用。这个报告里平均每秒的指标的值是当前的，可以看作是实时的，其它的值则是累加的，是从数据库启动以来的累加值。因此，使用这个报告做性能分析，需要去一个时间段的两个报告，进行对比分析。本文就是这样做的，在sysbech测试运行期间获取了两个报告，对这两个报告的各个部分进行对比分析。

获取InnoDB引擎状态报告的命令是

mysql> show engine innodb status\G;

a 报告的概况

-- rpt1
Type: InnoDB
  Name:
Status:
=====================================
2022-08-25 10:00:12 0x7fa4b4079700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 61 seconds

--rpt2
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2022-08-25 10:02:27 0x7fa4b4079700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 13 seconds

两个报告的时间间隔稍大于2分钟，第一个报告的平均值计算间隔是过去60秒至当前时间，第二个报告的平均值是过去13秒至当前时间。

b 后台线程

rpt1
-----------------
srv_master_thread loops: 1269 srv_active, 0 srv_shutdown, 58571 srv_idle
srv_master_thread log flush and writes: 59840
----------
rpt2
-----------------
srv_master_thread loops: 1403 srv_active, 0 srv_shutdown, 58571 srv_idle
srv_master_thread log flush and writes: 59974
----------

这个部分是主线程的活跃情况，这个值是累加值，通过比较这两个报告的值，可以看出，在这两分钟多的时间内，主线程活跃了143个loop，而空闲loop没有变化，这说明这段间隔内主线程都是活跃的，数据库负载比较大。主线程执行log刷新和写144次，这段时间内产生日志比较频繁。

c 信号量

这部分可以看到cpu的加锁情况

--rpt1
----------
OS WAIT ARRAY INFO: reservation count 6296
OS WAIT ARRAY INFO: signal count 4796
RW-shared spins 0, rounds 2451, OS waits 900
RW-excl spins 0, rounds 27026, OS waits 925
RW-sx spins 184, rounds 5459, OS waits 101
Spin rounds per wait: 2451.00 RW-shared, 27026.00 RW-excl, 29.67 RW-sx
------------
--rpt2
----------
OS WAIT ARRAY INFO: reservation count 6903
OS WAIT ARRAY INFO: signal count 5282
RW-shared spins 0, rounds 2644, OS waits 968
RW-excl spins 0, rounds 29387, OS waits 1013
RW-sx spins 196, rounds 5819, OS waits 106
Spin rounds per wait: 2644.00 RW-shared, 29387.00 RW-excl, 29.69 RW-sx
------------

这部分指标十分重要，因为它反映了数据库的锁的获取情况，可以看到OS waits的值有了不小的增长，说明了数据库的并发有问题。innodb采用多阶段锁等待策略，如果一个线程不能获得RW锁，它会首先进入spin-wait阶段，这个阶段线程仍然占用cpu，执行了一定数量的pause CPU指令（rounds）后会尝试再次获得锁。如果经历了n次spin-wait后仍然不能获得锁，则进入wait数组，等待操作系统唤起。进入os wait的线程会释放CPU，进行context switch，这个操作更复杂，代价更高。

Spin rounds per wait的值是指每次spin经过多少个round后获得锁，这里的wait是指spin wait，不是os wait，这个可以从RW-sx的值29.69乘以RW-sx的数量196等于RW-sx的rounds数5819推测出来。

d TRANSACTIONS

这个部分显示的数据库当前的事务，是实时的信息，只要看最后一个报告的相关内容就可以了。

--rpt2
------------
Trx id counter 1552274
Purge done for trx's n:o < 1552274 undo n:o < 0 state: running but idle'
History list length 138
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421820672464272, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421820672463360, not started flushing log
mysql tables in use 1, locked 1
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421820672462448, not started flushing log
mysql tables in use 1, locked 1
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421820672461536, not started flushing log
mysql tables in use 1, locked 1
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421820672460624, not started flushing log
mysql tables in use 1, locked 1
0 lock struct(s), heap size 1136, 0 row lock(s)

History list length 是undo中活跃事务的数量，后面列出了每个会话打开事务。

e FILE I/O

这个部分也是只看一个报告即可

--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: complete io for buf page (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
 ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 1; buffer pool: 1
2236 OS file reads, 575444 OS file writes, 443730 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 444.68 writes/s, 354.98 fsyncs/s

第十六行是当前的均值，据此可以判断数据库的IO情况。

f INSERT BUFFER AND ADAPTIVE HASH INDEX

这个部分显示了插入缓冲区和自适应索引的使用情况，只看一个报告即可

-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 2 buffer(s)
Hash table size 34679, node heap has 153 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 154 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
2397.90 hash searches/s, 3331.40 non-hash searches/s

第15行显示了每秒哈希查找和非哈希查找的次数，哈希表中也可以看到缓冲，可以看到innodb使用了自适应哈希索引技术对查询进行了优化。

g log

这个部分是innodb redo log的信息，可以看到有一个待处理的log 刷新，log io为349.56 个每秒。如果pending log flushes过于频繁，可能是事务过多或者是log所在的设备io能力不足。

h BUFFER POOL AND MEMORY

----------------------
Total large memory allocated 137428992
Dictionary memory allocated 319614
Buffer pool size   8192
Free buffers       1024
Database pages     6857
Old database pages 2511
Modified db pages  1830
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 11055, not young 3790
0.00 youngs/s, 0.00 non-youngs/s
Pages read 2207, created 6631, written 136280
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6857, unzip_LRU len: 0
I/O sum[4668]:cur[91], unzip sum[0]:cur[0]
--------------

这个部分是innodb缓存信息，可以看到缓冲区分配的内存、剩余的缓冲等信息，evicted without access 0.00/s可以判断缓冲区是否充足，这个值为0，说明缓冲区是中充足的，没有发生缓冲区被淘汰的现象。

i ROW OPERATIONS

0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=46748, Main thread ID=140345398290176, state: sleeping
Number of rows inserted 600430, updated 400893, deleted 200431, read 83585599
160.03 inserts/s, 320.06 updates/s, 160.05 deletes/s, 66733.40 reads/s

这部分是行操作的信息，第五行的信息有助于我们判断数据库的负载情况。

5 查找线程执行的sql语句

前面的部分曾经说明怎样用top命令查看mysql线程的cpu利用率，假设已经找到了cpu利用率异常的线程，怎样找到这个线程是哪个线程，执行的是什么语句。可以用下面的语句来查询。

select pr.id,pr.host,pr.db,pr.command,pr.time,pr.state,pr.info
        from performance_schema.threads th,information_schema.processlist pr
           where pr.id=th.PROCESSLIST_ID and th.THREAD_OS_ID=46777;