background
使用Mysql原生自带的性能分析工具——performance_schema库（mysql的性能监控功能）
profiling功能在5.6开始逐渐被performance_schema取代,information_schema中部分性能数据收集迁移到了performance_schema中。
In a word, the P_S library is worth learning, and its reasonable use will help us analyze the database.
The official interpretation of the document
https://github.com/xiaoboluo768/mysql-system-schema/wiki/performance_schema%E8%AF%A6%E8%A7%A3
link
SHOW VARIABLES LIKE'performance_schema';
By default, the performance mode is enabled. To enable or disable it explicitly, start the server with the performance_schema variable set to an appropriate value. For example, use the following line in the server my.cnf file:
[mysqld]
performance_schema=ON
MySQL CPU suddenly becomes high, what should I do?
以下操作的说明，因为linux的系统线程thread_os_id和mysql的线程PROCESSLIST_ID不是一一对应的 并且步骤2中的语句，在事务commit或是sleep之后，就不会显示具体的语句信息了PROCESSLIST_INFO。 这里只想说明的是，我们在平时使用时，应该正确的Kill掉PROCESSLIST_ID。
0.本次使用的是压测工具模拟高负载的情况
./tpcc_start -h192.168.66.133 -P 17261 -d tpcc -u msandbox -p123456 -w 5 -c 5 -r 120 -l 600 - >test0118/tpcc-output-log
1. top -H 找到 CPU 高的线程
这里可以看到 CPU 高的线程一直是 33055,但是其他PID才是正在要分析的
2.select * from performance_schema.threads where thread_os_id = 109784\G;
3.和开发确认是否要kill掉PROCESSLIST_ID: 1805
持续一直为某个PID CPU使用率高>80%,一般看下show processlist,会有对应的ID(kill 它就行，它和PROCESSLIST_ID一样)
1.
2.
可以看到很多有用的信息：
1. 可以看到 processlist 中对应线程的信息
2. 可以找到其在 processlist 中的 ID，这样我们就可以下 kill 命令来结束 SQL
小贴士：
使用 performance_schema 时，需要大家注意 MySQL 使用了多个线程编号，源自于不同视角：
1. PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者可以直接用 kill 命令。
2. THREAD_ID：是 MySQL 内部使用的线程编号，是 MySQL 内部视角的编号。
3. THREAD_OS_ID：是在操作系统上，对应的线程编号，是操作系统视角的编号。
大家使用时需要区分好，不要 kill 错了 SQL。
test
供读者使用的测试语句（来自互联网资料）
1.造数据：
create table t1(x int primary key auto_increment)
insert into t1 () values (),(),(),()
insert into t1(x) select x +(select count(*) from t1) from t1;
2.select * from t1 order by rand() limit 1; (慢sql查询)
之后使用上面的3个步骤，进行分析。
通过上述,可以了解到以下几点：
1.连接管理线程会为每一个connection分配一个mysql thread来处理
2.mysql thread实际会使用某个os thread来处理请求
3.connection关闭或kill mysql thread时，mysql thread会销毁，但是os thread可以继续复用
The relationship of the three is as follows:
mysql will create a corresponding mysql thread for each connection. After the connection is closed, the life cycle of the mysql thread is also terminated. This mysql thread can be viewed in the processlist and threads table.
Each mysql threard will be associated with an os thread. After the mysql thread is destroyed, the os thread will not be destroyed and can be used by other mysql threads.
If all os threads are mysql The thread is used up, a new os thread will be created when the next connection request is made
mysql 官方说明：访问threads表对mysql没有什么性能影响，但访问processlist表或者show processlist对性能有一定影响，因为它们都需要mutex(互斥) performance.threads 表中有 thread_os_id 字段，存储了mysql thread和os thread的关系
select thread_id,`name`,type,processlist_id,thread_os_id from performance_schema.threads where name ='thread/sql/one_connection';
不过本身找到mysql thread对应的os thread也没什么意义.
Table usage
那些业务表很繁忙？
查询某张表tpcc.orders上没有使用主键，并且索引是 not null的请求总数（io等待相关COUNT_STAR为数量值）。
select OBJECT_SCHEMA,OBJECT_NAME,INDEX_NAME,COUNT_STAR from performance_schema.table_io_waits_summary_by_index_usage where OBJECT_SCHEMA='tpcc' and OBJECT_NAME='orders' and INDEX_NAME is not null and INDEX_NAME<>'PRIMARY' order by COUNT_STAR;
查询整个库：
select OBJECT_SCHEMA,OBJECT_NAME,INDEX_NAME,COUNT_STAR from performance_schema.table_io_waits_summary_by_index_usage where OBJECT_SCHEMA='tpcc' and INDEX_NAME is not null and INDEX_NAME<>'PRIMARY' order by COUNT_STAR;
InooDB 控制刷脏页的策略:
为了避免这种情况，要合理的设置 innodb_io_capacity 的值，平时要多关注脏页比例，不让其接近 75%.
初次之外，在一个查询操作进行时，如果需要 flush 脏页的话，如果这个该脏页的邻居也是脏页的话，就会把这个邻居一起刷掉，如果恰好旁边还是脏页的话，就会一直连坐。这时导致 flush 过慢的原因。
可以通过 innodb_flush_neighbors 来控制该行为，值为 1 打开上述机制，为 0 则关闭。
对于机械硬盘来说，是可以减少很多随机 IO ，因为机械硬盘 IOPS 一般就几百，减少随机 IO 就意味着性能提升。
但如果用 SSD 这类 IOPS 较高的设备，IOPS 往往不是瓶颈，关闭就好，减少 SQL 语句的响应时间。
在 8.0 中，已经默认是 0 了.
其中脏页比例可以通过下面的方式获取：（临时的）
select VARIABLE_VALUE into @a from performance_schema.global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_dirty';
select VARIABLE_VALUE into @b from performance_schema.global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_total';
select @a/@b;
压测：(模拟数据更新)
./tpcc_start -h192.168.66.133 -P 17261 -d tpcc -u msandbox -p123456 -w 5 -c 5 -r 120 -l 600 - >test0118/tpcc-output-log
Permissions issue
与SHOW processlist；语句输出信息一样，如果你没有process权限，则只能看到你自己的线程信息，如果有super权限，则可以看到所有其他用户的线程信息，如果是匿名用户，则不能看到任何线程信息 INFORMATION_SCHEMA.PROCESSLIST表中只记录线程当前正在执行的语句信息，一旦语句执行完成，或者是多语句的事务中，先执行完成的语句，在该表中是无法查看到的
This article explains that the main technical content comes from the sharing of Internet technology giants, as well as some self-processing (only for the role of annotations). If related questions, please leave a message after the confirmation, the implementation of infringement will be deleted