背景
使用Mysql原生自带的性能分析工具——performance_schema库（mysql的性能监控功能）
profiling功能在5.6开始逐渐被performance_schema取代,information_schema中部分性能数据收集迁移到了performance_schema中。
一言以蔽之,P_S库值得我们学习，对它的合理使用，有利于我们对数据库进行分析
官方文档的解读
https://github.com/xiaoboluo768/mysql-system-schema/wiki/performance_schema%E8%AF%A6%E8%A7%A3
link
SHOW VARIABLES LIKE ‘performance_schema’;
默认情况下，性能模式处于启用状态。要显式启用或禁用它，请在将performance_schema变量设置为适当值的情况下启动服务器 。例如，在服务器my.cnf文件中使用以下行：
[mysqld]
performance_schema=ON
MySQL CPU 突然高了，怎么办？
以下操作的说明，因为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。
测试
供读者使用的测试语句（来自互联网资料）
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可以继续复用
三者的关联如下：
mysql会为每个connection创建一个对应mysql thread，连接关闭后，mysql thread生命周期也终止。这个mysql thread可以在processlist、threads表中查看
每个mysql threard将与一个os thread关联在一起，mysql thread销毁后，os thread不会被销毁，可以继续给其他mysql thread使用
如果所有os thread都被mysql thread用光了，下一个connection请求时将会创建新的os thread
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也没什么意义.
表的使用情况
那些业务表很繁忙？
查询某张表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
权限问题
与SHOW processlist；语句输出信息一样，如果你没有process权限，则只能看到你自己的线程信息，如果有super权限，则可以看到所有其他用户的线程信息，如果是匿名用户，则不能看到任何线程信息 INFORMATION_SCHEMA.PROCESSLIST表中只记录线程当前正在执行的语句信息，一旦语句执行完成，或者是多语句的事务中，先执行完成的语句，在该表中是无法查看到的
本文说明，主要技术内容来自互联网技术大佬的分享，还有一些自我的加工(仅仅起到注释说明的作用)。如有相关疑问，请留言，将确认之后，执行侵权必删