1 环境描述
这里的环境是一个阿里云ECS的实例，在上面安装了MySQL ５.７ ，用sysbench给数据库加压，使用读写测试脚本，模拟真实业务的场景。
ECS是配置比较低的入门级实例，具体的配置见下图：
MySQL数据库安装的是5.7的版本，详细信息如下：
mysql>select version();+-----------+| version()|+-----------+|5.7.34|+-----------+1 row inset(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: 4461870write: 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: 318656Latency (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 ALLLinux 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 00.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 03.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 033.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 033.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 033.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 08.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 -dLinux 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 -WLinux 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 3procs -----------memory-------------swap-------io-----system--------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 900316524500922444001161106191622951021031646450092244400054743344147053720231900003164965009224440005358333614675342424190
这个命令的输出里面包含了很多有用的信息，报告里面的第一行的值是从服务器上一次启动以来的平均值，后面的报告就是这个时间间隔内的平均值了，看当前的性能要从第二行开始看起。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 3Linux 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 99413626792640010avg-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 05325avg-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 05401
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 46748top-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 200116795233836022532 S 6.2 18.2 1:09.31 mysqld 48993 mysql 200116795233836022532 S 6.2 18.2 1:09.27 mysqld 49091 mysql 200116795233836022532 S 6.2 18.2 1:07.80 mysqld 49092 mysql 200116795233836022532 D 6.2 18.2 1:07.85 mysqld 46748 mysql 200116795233836022532 S 0.0 18.2 0:00.27 mysqld 46749 mysql 200116795233836022532 S 0.0 18.2 0:00.00 mysqld 46750 mysql 200116795233836022532 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 safemysql 46748466491 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 报告的概况
-- rpt1Type: InnoDB Name:Status:=====================================2022-08-2510:00:120x7fa4b4079700 INNODB MONITOR OUTPUT =====================================Per second averages calculated from the last 61 seconds --rpt2***************************1. row *************************** Type: InnoDB Name:Status:=====================================2022-08-2510:02:270x7fa4b4079700 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 count6296OS WAIT ARRAY INFO: signal count4796RW-shared spins 0, rounds 2451, OS waits 900RW-excl spins 0, rounds 27026, OS waits 925RW-sx spins 184, rounds 5459, OS waits 101Spin rounds per wait:2451.00 RW-shared,27026.00 RW-excl,29.67 RW-sx --------------rpt2----------OS WAIT ARRAY INFO: reservation count6903OS WAIT ARRAY INFO: signal count5282RW-shared spins 0, rounds 2644, OS waits 968RW-excl spins 0, rounds 29387, OS waits 1013RW-sx spins 196, rounds 5819, OS waits 106Spin 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 1552274Purge done for trx's n:o < 1552274 undo n:o < 0 state: running but idle'History list length 138LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 421820672464272, not started0 lock struct(s), heap size 1136,0 row lock(s)---TRANSACTION 421820672463360, not started flushing logmysql tables in use 1, locked 10 lock struct(s), heap size 1136,0 row lock(s)---TRANSACTION 421820672462448, not started flushing logmysql tables in use 1, locked 10 lock struct(s), heap size 1136,0 row lock(s)---TRANSACTION 421820672461536, not started flushing logmysql tables in use 1, locked 10 lock struct(s), heap size 1136,0 row lock(s)---TRANSACTION 421820672460624, not started flushing logmysql tables in use 1, locked 10 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:12236 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:insert0,delete mark 0,delete0discarded operations:insert0,delete mark 0,delete0Hash 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
---Log sequence number 10906687452Log flushed up to 10906685797Pages flushed up to 10896741683Last checkpoint at 108948208421 pending log flushes,0 pending chkp writes 435720 log i/o's done, 349.56 log i/o's/second ----------------------
这个部分是innodb redo log的信息，可以看到有一个待处理的log 刷新，log io为349.56 个每秒。如果pending log flushes过于频繁，可能是事务过多或者是log所在的设备io能力不足。
h BUFFER POOL AND MEMORY
----------------------Total large memory allocated 137428992Dictionary memory allocated 319614Buffer pool size 8192Free buffers 1024Database pages 6857Old database pages 2511Modified db pages 1830Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages made young 11055,not young 37900.00 youngs/s,0.00 non-youngs/s Pages read 2207, created 6631, written 1362800.00 reads/s,0.00 creates/s,0.00 writes/s Buffer pool hit rate 1000/1000, young-making rate 0/1000not0/1000Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len:6857, unzip_LRU len:0I/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 83585599160.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.infofrom performance_schema.threads th,information_schema.processlist pr where pr.id=th.PROCESSLIST_IDand th.THREAD_OS_ID=46777;
