1）检查当时的主机资源状态，其cpu 内存，磁盘IO 负载实际都并不高。 复查主机资源发现当时的load avage指标异常，1分钟平均负载量达到100以上，5分钟平均负载量达到90以上，10分钟平均负载量达到60以上，说明当时cpu的运行队列出现排队现象。
2)当时的thread cache size 分别出现两次耗尽情况，大量的线程处于running的状态。
3）从后台慢日志看，show variables 语句每次执行都超过了10秒钟，该sql正常情况执行时间为不到0.1秒钟，这是非正常现象。
4）从当时的processlists来看，将近90%的活动会话在执行show variables 语句，其状态主要是在Sending data （约70%） 和preparing （约15%）上。
关于 sending data解析：
|
sending data 是指在存储引擎和服务器上层之间进行数据交换，不只是在向客户端发送任何数据阶段。当服务器执行一个查询时，这主要发生在两个层面。 它发生在 SQL Server 层，在那里解析查询，检索数据， 然后可以做进一步的处理（ filter 、 sort 、 group 、 join ），再将结果返回给客户机以及存储引擎（ InnoDB ， MyISAM ）层等一系列阶段。 |
在 MYSQL 5.7环境模拟了大量并发的会话执行"show variables"的操作，同样可以看到大量会话堵塞在Sending data状态，通过跟踪线程堆栈信息，发现大量的show variables 语句在Sending data状态都是在申请线程mutex锁时发生了锁等待。因此可以说明大量并发的show variables 语句执行时，会因为大量的线程mutex锁争用，而引起会话阻塞堆积。从上面的主机资源情况也可以看出，cpu并不高，但是load avage 比较高是因为线程的锁申请等待引起的排队。
测试结果 ：
|
+--------------+------+-------------------+-----------+---------+------+--------------+----------------+ | THREAD_OS_ID | user | host | db | command | time | state | info | +--------------+------+-------------------+-----------+---------+------+--------------+----------------+ | 26089 | root | ACS-SCN-DB1:48088 | employees | Query | 0 | Sending data | SHOW VARIABLES | 《《《《《《《 ====== 处于 Sending data 状态
Thread 187 (Thread 0x7fa8149c6700 ( LWP 26089)): #0 0x00007fa8dadb354d in __lll_lock_wait () from /lib64/libpthread.so.0 《《《《《《《 ====== 锁等待 #1 0x00007fa8dadaeed1 in _L_lock_1093 () from /lib64/libpthread.so.0 《《《《《《《 ====== L_lock_1093 () #2 0x00007fa8dadaee72 in pthread_mutex_lock () from /lib64/libpthread.so.0 《《《《《《《 ====== 线程互斥锁
#3 0x00000000011df234
in native_mutex_lock (mutex=
#4 my_mutex_lock (mp=
#5 inline_mysql_mutex_lock (src_line=80, src_file=0x17f10f0 "/export/home/pb2/build/sb_0-37309218-1576676677.02/mysql-5.7.29/storage/perfschema/table_session_variables.cc", that= #6 table_session_variables::get_row_count () at /export/home/pb2/build/sb_0-37309218-1576676677.02/mysql-5.7.29/storage/perfschema/table_session_variables.cc:80
#7 0x0000000001185fdf in ha_perfschema::info (this=0x7fa6c806a000, flag=
#8 0x0000000000d8f125 in make_join_readinfo (join=0x7fa7ec0707d0, no_jbuf_after= 。。。。。。 (thd=0x7fa7ec037630, com_data=0x7fa8149c5da0, command=COM_QUERY) at /export/home/pb2/build/sb_0-37309218-1576676677.02/mysql-5.7.29/sql/sql_parse.cc:1491 #20 0x0000000000d529e4 in do_command (thd=0x7fa7ec037630) at /export/home/pb2/build/sb_0-37309218-1576676677.02/mysql-5.7.29/sql/sql_parse.cc:1032
#21 0x0000000000e24dcc in handle_connection (arg= #22 0x0000000001188c74 in pfs_spawn_thread (arg=0x7d25480) at /export/home/pb2/build/sb_0-37309218-1576676677.02/mysql-5.7.29/storage/perfschema/pfs.cc:2197 #23 0x00007fa8dadacea5 in start_thread () from /lib64/libpthread.so.0 #24 0x00007fa8d98658cd in clone () from /lib64/libc.so.6
|
5）关于SHOW VARIABLES 的来源，SHOW VARIABLES是MYSQL connector/.NET 默认带上的，它在每次连接时都会发起一次查询SHOW VARIABLES去获取需要的相关信息。当前的mysql数据库在高峰期的短连接量较大，随之而来的是大量的SHOW VARIABLES查询。
针对 SHOW VARIABLES官方是可以建议关闭该属性，描述及方法如下：
|
Configure MySQL Connector/.NET to Avoid Executing SHOW VARIABLES Command with Each New MySQL Connection (Doc ID 2106146.1)
SOLUTION With following connection string parameter new connections will not execute SHOW VARIABLES command : CacheServerProperties=true Also waiting for the feature request to be implemented: https://bugs.mysql.com/bug.php?id=93202
REFERENCES https://dev.mysql.com/doc/connector-net/en/connector-net-connection-options.html https://bugs.mysql.com/bug.php?id=93202
|