---------------------------- ----------------
1.1.3. show slave status
作用：查询slave的状态。
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: mysql101.coe2coe.me
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 2781
Relay_Log_File: mysql102-relay-bin.000016
Relay_Log_Pos: 2994
Relay_Master_Log_File: mysql-bin.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: mysql.%,information_schema.%,performance_schema.%,sys.%
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 2781
Relay_Log_Space: 3370
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 101
Master_UUID: a2392929-6dfb-11e7-b294-000c29b1c101
Master_Info_File: /opt/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
多少个至关首要的条文的意义如下：
Slave_IO_Running: slave上的和master的用于复制的互连网连接的IO线程是不是在运行中，用于收纳来自master的Binary Log，并保存到slave本地的Relay Log中。
Master_Log_File: mysql-bin.00000七 读取master上的这些Binary Log文件。
Read_Master_Log_Pos: 2781 读取的master上的Binary Log的位置。
Relay_Log_File: mysql十二-relay-bin.00001陆 本地保存的Relay Log文件。
Relay_Log_Pos: 29玖肆 本地保存的Relay Log的职责。
Slave_SQL_Running: slave上的SQL线程是不是在运转中，用于读取slave当地的Relay Log，并实行在那之中的数据库操作，然后保留到slave本地的Binary Log中。
Relay_Master_Log_File: mysql-bin.00000七 正在联合master上的Binary Log文件。
Exec_Master_Log_Pos: 2781 正在联合的任务。
Seconds_Behind_Master：slave的SQL线程施行的事件的日子戳和IO线程已封存的风浪的日子戳的差值。此值为0意味着复制品质非凡。此值用于描述slave相对于master的推移的秒数，不过其实在十分规景况下只可以浮现出slave的IO线程和SQL线程之间的延迟。在slave和master之间的网络通信情状不好时，此值为0，可是slave和master之间大概早就不相同台了。
*************************** 2. row
***************************
CHANNEL_NAME:
WORKER_ID: 2
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: ANONYMOUS
LAST_ERROR_NUMBER: 1168
LAST_ERROR_MESSAGE: Worker 2 failed executing transaction 'ANONYMOUS'
at master log mysql-bin.005656, end_log_pos 4529152; Error executing
row event: 'Uerlying table which is differently defined or of non-MyISAM
type or doesn't exist'
LAST_ERROR_TIMESTAMP: 2017-12-01 08:57:55
二三.九 质量框架表描述
3rows inset ( 0. 01sec)
1.1.4. start slave
效果：运转slave复制相关线程，包罗IO线程和SQL线程，也能够独自运维IO线程只怕独立运营SQL线程。
语法:
START SLAVE [thread_types] [until_option] [connection_options] [channel_option]
thread_types:钦点要运转的线程类型。
[thread_type [, thread_type] ... ]
线程类型包涵IO_THREAD和SQL_THREAD。
until_option:钦定复制停止地点。
UNTIL { {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
| MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
| RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
| SQL_AFTER_MTS_GAPS }
行使Binary Log格局的复制时，钦赐MASTE卡宴_LOG_FILE和MASTER_LOG_POS参数，使用GTID格局的复制时，钦赐SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS参数。
mysql> start slave;
Query OK, 0 rows affected (0.02 sec)
在从库中查看表performance_schema.replication_applier_status_by_worker
select * from
performance_schema.replication_applier_status_by_workerG
23.9.3.5 socket_instance表
Socket_instancees表提供了一个实时的连接活动快速照相。各种tcp/ip连接有一行，或然每种unix socket file连接有一行。
mysql> SELECT * FROM socket_instancesG
*************************** 1. row ***************************
EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408
THREAD_ID: 1
SOCKET_ID: 16
IP:
PORT: 0
STATE: ACTIVE
*************************** 2. row ***************************
EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608
THREAD_ID: 21
SOCKET_ID: 39
IP: 127.0.0.1
PORT: 55233
STATE: ACTIVE
*************************** 3. row ***************************
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040
THREAD_ID: 1
SOCKET_ID: 14
IP: 0.0.0.0
PORT: 50603
STATE: ACTIVE
socket记录点名字格式，wait/io/socket/sql/socket_type：
1.服务有多个监听socket，记录点那么socket_type的值为server_tcpip_socket或者server_unix_socket``。
二. 当有1个监听socket发现一个延续，那么服务会转接到三个新的socket来保管，server_type类型为client_connection。
3. 当1个接连中断，那么行会在socket_instances中删除。
Socket_instances表类如下：
· EVENT_NAME: wait/io/socket/*,具体的名字来至于setup_instruments表
· OBJECT_INSTANCE_BEGIN:socket的绝无仅有标志，值为对象在内部存款和储蓄器中的值。
· THREAD_ID:内部线程表示。种种socket由线程管理，所以种种socket被映射到2个线程。
· SOCKET_ID:socket内部的分配的公文句柄
· IP:客户端ip地址
· PORT：客户端端口地址
· STATE:socket状态要不是idle要不是active。假若线程等待client的伸手，那么景况正是idle。当socket形成idle，表中的STATE也会形成IDLE，socket的记录点中断。当呼吁出现idle中断，产生ACTIVE。Socket的记录点timing复苏。
IP:PORT组合来代表三个实惠的连日。组合值被用于events_waits_xxx表的object_name，来标识连接来至于何地：
· 来至于unix域监听socket，端口是0，ip为‘’
· 对于经过unix域监听的socket，端口是0，ip为‘’
· 对于tcp/ip的监听，端口是劳务的端口，默认为330六，ip为0.0.0.0
· 对于通过tcp/ip连接的客户端接口，端口不为0，ip是客户端的ip。
1.replication_applier_configuration表
1.1.2. show slave hosts
意义：查询已经注册到master上的slave的信息。
mysql> show slave hosts;
----------- ------ ------ ----------- --------------------------------------
| Server_id | Host | Port | Master_id | Slave_UUID |
----------- ------ ------ ----------- --------------------------------------
| 103 | | 3306 | 101 | a2392929-6dfb-11e7-b294-000c29b1c103 |
| 102 | | 3306 | 101 | a2392929-6dfb-11e7-b294-000c29b1c102 |
----------- ------ ------ ----------- --------------------------------------
2 rows in set (0.00 sec)
Server_id：slave上的MySQL的server_id。
Host：slave的主机名。
Port：slave上的MySQL的端口号。
Master_id：master上的MySQL的server_id。
Slave_UUID：slave上的MySQL的UUID。
二三.九.1一 质量框架复制表
MySQL 五.七.二,品质框架提供了有关复制消息的表。和show slave status的新闻类似：
· Show slave status输出能够翻阅进行检讨，不过不可能用来编制程序使用。
· 查询结果能够保存到表中，用于分析，设置变量，或许在仓库储存进程上应用。
· 复制表提供了更加好的确诊消息，对于多线程slave操作，show slave status使用last_SQL_Errorno和last_sql_error字段报告富有的协调器和办事线程的不当。所以唯有近来的荒唐工夫看得出。复制表会为各样线程上的谬误保存消息不会丢掉。
· 每种工作线程的前卫的作业在在复制表是可知的。不过show_slave_status。不可见。
· 开垦熟识的属性框架接口能够增添复制表提供越多的消息。
复制表描述
个性框架提供一下和复制有关的表：
· 关于Slave连接到master的接连新闻表：
§ Replication_connection_configuration：配置连接到master的参数。
§ Replication_connection_status:当前再而三到master的状态。
· 关于slave事务应用的表
§ replication_applier_configuration:slave海南中华南理艺术大学程集团作应用的配备新闻。
§ replication_applier_status:当前作业应用的情事。
· 关于内定线程应用从master获取职业并奉行的消息：
§ Replication_applier_status_by_coordinator:applier线程状态，在此之前叫replication_execute_status_by_coordinator。对于有两个work thread的复制有八个work thread和二个体协会调线程，对于单线程的这么些表为空。
§ Replication_applier_status_by_worker:工作线程应用状态。同上单线程复制表为空。
· 包括复制组成员消息的表：
§ Replication_group_members:提供互连网和组成员状态。
§ Replication_group_member_status:提供组成员的总计消息和参预的作业。
复制表生命周期
质量框架在以下情况下写入复制表：
· 在进行change master to此前表为空。
· 在施行change master to之后。配置演说能够在表上发现。如若那年从不挪动的slave 线程，那么thread_id列为null，serivce_state的事态为off。
· Start slave之后，没有thread_id字段不为空。线程为空闲或然活动service_status状态为on。线程连接到master server，如若连接建立有个connecting值。
· Stop slave之后，thread_id为null，并且service_State列值为off。
· Stop slave大概thread境遇错误，表信息会被保存。
· Replication_applier_Status_by_worker表唯有当slave操作在二1010二线程情势下为非空。尽管slave_parallel_workers变量大于0，那么start slave之后，行数和线程个数一样多。
SHOW SLAVE STATUS不再复制表中的新闻
Show slave status的消息和复制表中的新闻分裂，因为这个表首就算面向GTID的复制。不是依据文件名和职位：
· 以下字段关于文件名和职位的从未有过保留：
Master_Log_File
Read_Master_Log_Pos
Relay_Log_File
Relay_Log_Pos
Relay_Master_Log_File
Exec_Master_Log_Pos
Until_Condition
Until_Log_File
Until_Log_Pos
· Master_info_file字段未有保留。参照master.info文件。
· 以下字段基于server_id,不是server_uuid，未有被封存：
Master_Server_Id
Replicate_Ignore_Server_Ids
· Skip_counter列依照事件个数，不是gtid未有被封存。
· 错误列是last_sql_errno,last_sql_error的外号，由此不被保存
Last_Errno
Last_Error
在性质框架中，replication_applier_status_by_coodinator和表replication _applier_status_by_worker中的last_error_number和last_error_message列保存了错误音讯。
· 命令行过滤操作的消息不被保留：
Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
· Slave_io_State和slave_sql_running_state列未有保存。如若需求能够因而thread_id关联上perocesslist表获取表中的status值。
· Executed_gtid_set字段可以显得大量的文字。和性质框架表中展现已经被slave应用的事体的GTID。已经被推行的GTID能够由此gtid_executed系统变量获取。
· Seconds_behind_master和relay_log_spae用来就要被决定的情形不保留。
状态变量移动到了复制表
从mysql 伍.七.5,以下处境被挪动到了品质框架复制表：
Slave_retried_transactions
Slave_last_heartbeat
Slave_received_heartbeats
Slave_heartbeat_period
Slave_running
那个变量用于单源复制，因为只可以反映私下认可源复制。当有八个复制源，能够使用质量复制表，汇报各种复制路子的意况。
多源复制
品质框架表的第贰列是channel_name.能够看出各种复制源。
# session_status表（记录内容与global_status 表类似）
1.1.6. reset slave
效果：清除slave上安装的复制关系。
语法：RESET SLAVE [ALL]
reset slave命令将消除slave上的关于master的复制新闻，比如slave保存在master.info文件中的master上的Binary Log文件的岗位；还会删除slave本地的Relay Log文件。
reset slave命令并不会去掉mysql.gtid_executed数据表或gtid_purged系统变量；reset slave命令也不会化解关于slave和master的接二连三参数，比如master的IP地址和端口。
reset slave all除了拔除reset slave清除掉的始末之外，还会化解slave和master的接连参数。
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> reset slave all;
Query OK, 0 rows affected (0.00 sec)
查看这几个ID为33贰的那张表，发现那张表是自行创设的，创制的时候从不点名存款和储蓄引擎，所以基本都出错了
二3.2.叁 运行时品质框架配置
7. replication_group_member_stats表
1.1.7. reset master
reset master命令将去除在mysql-bin.index文件中列出的装有的Binary Log文件;同时还会清空gtid_purged那么些只读的种类变量;同时还会清空mysql.gtid_executed数据表。这些操作使得slave将从上马地点再次开始展览与master的联合签名。
mysql> reset master;
Query OK, 0 rows affected, 1 warning (0.04 sec)
Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 2 failed executing transaction 'ANONYMOUS' at master log mysql-bin.005656, end_log_pos 4529152. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
二三.二.三.三.叁 线程预过滤
threads表为各类线程保存了一条龙数据。每行数据都富含了线程的消息并且评释是还是不是被监察和控制。对于质量框架监察和控制3个线程必须满意一下他条件：
· 表sestup_consumers表中的thread_instrumentation必须为yes
· Threads.instrumented列必须为yes
· 只监控setup_instruments表中的记录点
threads表也表达了各类服务线程是否奉行历史事件记录。假如要记录历史事件以下原则都无法不为真：
· 对应的买主配置，setup_consumers表必须为yes。
· Threads.HISTO奇骏Y列必须为yes。
· 只监控setup_instruments表中的记录点
对此后台线程，instrumented和history的起来数据，取决于setup_action中的配置。
mysql> SELECT * FROM setup_actors;
------ ------ ------ --------- ---------
| HOST | USER | ROLE | ENABLED | HISTORY |
------ ------ ------ --------- ---------
| % | % | % | YES | YES |
------ ------ ------ --------- ---------
thread表的instrumented和history的条条框框如下：
· 假设最好相配，enabled=yes,那么instrumented=yes，最好匹配history=yes,那么threads表的history=yes
· 借使最好相配，enabled=no,那么instrumented=no，最棒相配history=no,那么threads表的history=no
· 借使不能同盟，那么instrumented，history都为no
在mysql 五.七.6 从前，未有enabled字段，只要有合营，那么instrumented=yes
在mysql5.七.八,以前，未有history字段，线程要不全部方可进入history要不都不可能，取决于setup_consumer的配置。
暗中同意，后台的有着线程都是会被记录的，因为setup_actors有壹行都以‘%’。
1.1.8. 连天景况
使用品质数据库中的复制相关数据表，能够查看复制相关的性情数据。
mysql> use performance_schema;
Database changed
复制连接配置表：
mysql> select * from replication_connection_configurationG
*************************** 1. row ***************************
CHANNEL_NAME: master111
HOST: 192.168.197.111
PORT: 3306
USER: repl
NETWORK_INTERFACE:
AUTO_POSITION: 1
SSL_ALLOWED: NO
SSL_CA_FILE:
SSL_CA_PATH:
SSL_CERTIFICATE:
SSL_CIPHER:
SSL_KEY:
SSL_VERIFY_SERVER_CERTIFICATE: NO
SSL_CRL_FILE:
SSL_CRL_PATH:
CONNECTION_RETRY_INTERVAL: 60
CONNECTION_RETRY_COUNT: 86400
HEARTBEAT_INTERVAL: 30.000
TLS_VERSION:
*************************** 2. row ***************************
CHANNEL_NAME: master110
HOST: 192.168.197.110
PORT: 3306
USER: repl
NETWORK_INTERFACE:
AUTO_POSITION: 1
SSL_ALLOWED: NO
SSL_CA_FILE:
SSL_CA_PATH:
SSL_CERTIFICATE:
SSL_CIPHER:
SSL_KEY:
SSL_VERIFY_SERVER_CERTIFICATE: NO
SSL_CRL_FILE:
SSL_CRL_PATH:
CONNECTION_RETRY_INTERVAL: 60
CONNECTION_RETRY_COUNT: 86400
HEARTBEAT_INTERVAL: 30.000
TLS_VERSION:
2 rows in set (0.00 sec)
复制连接状态表：
mysql> select * from replication_connection_statusG
*************************** 1. row ***************************
CHANNEL_NAME: master111
GROUP_NAME:
SOURCE_UUID: a2392929-6dfb-11e7-b294-000c29b1c111
THREAD_ID: 35
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 36
LAST_HEARTBEAT_TIMESTAMP: 2017-08-18 12:54:09
RECEIVED_TRANSACTION_SET: a2392929-6dfb-11e7-b294-000c29b1c111:1-11
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
*************************** 2. row ***************************
CHANNEL_NAME: master110
GROUP_NAME:
SOURCE_UUID: a2392929-6dfb-11e7-b294-000c29b1c110
THREAD_ID: 33
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 35
LAST_HEARTBEAT_TIMESTAMP: 2017-08-18 12:54:03
RECEIVED_TRANSACTION_SET: a2392929-6dfb-11e7-b294-000c29b1c110:1-6
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
2 rows in set (0.00 sec)
image.png
二三.2.三.四命名记录点大概消费者的过滤
能够对点名记录名也许消费者进行过滤：
mysql> UPDATE setup_instruments
-> SET ENABLED = 'NO'
-> WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';
mysql> UPDATE setup_consumers
-> SET ENABLED = 'NO' WHERE NAME = 'events_waits_current';
钦点一组记录点大概消费者：
mysql> UPDATE setup_instruments
-> SET ENABLED = 'NO'
-> WHERE NAME LIKE 'wait/synch/mutex/%';
mysql> UPDATE setup_consumers
-> SET ENABLED = 'NO' WHERE NAME LIKE '%history%';
|| 3 |46| ON || 0 || 0000-00-00 00:00:00 |
1.1.1. show master status
作用：查询master的Binary Log状态。
mysql> show master status
-> ;
------------------ ---------- -------------- ------------------ -------------------
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
------------------ ---------- -------------- ------------------ -------------------
| mysql-bin.000007 | 2246 | | | |
------------------ ---------- -------------- ------------------ -------------------
1 row in set (0.00 sec)
以此命令须求super大概replication client权限，不然出现下边包车型地铁不肯访问错误。
mysql> show master status;
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation
去主库查找binlog日志，看看发生了什么样工作（日志定位情势有点挫）
mysqlbinlog --start-position=4529152 --stop-position=4539152
mysql-bin.005656 | more
那条命令是从452915二职务上马，可是大家失误的职位（end_log_pos）是以此职责截止，所以刚刚错开，再往前一点就好
了。
由此这条命令看到日志时间是2017-1二-0一 01:四柒:4壹，所以作者用了其余一条命令
mysqlbinlog --start-datetime=2017-12-01 01:47:41
--stop-datetime=2017-12-01 01:47:50 mysql-bin.005656 | more
找到日志：
23.9.11.7 replication_group_members
表保存了网络和复制成员组的情状音讯。Replication_group_members列：
· CHANNEL_NAME:复制来源名。
· MEMBER_ID:member标示，和uuid一样。
· MEMBER_HOST:host地址可能主机名。
· MEMBER_PORT:端口。
· MEMBER_STATE:
§ OFFLINE：group replication插件已经安装但是尚未运行。
§ RECOVEPAJEROING:服务已经参与到一个group，正在获取数据。
§ ONLINE:成员在全职能状态。
PS：
1.1. 复制的监督检查
23.9.11.1 replication_connection_configure表
表展现了连年到slave服务的连天配置。参数被保存在表中，在change master实行的时候会被退换。
replication_connection_configuration表蕴涵以下列：
· CHANNEL_NAME：复制源名。
· HOST:master的host名。
· PORT:master的端口
· USE陆风X8:连接用户
· NETWORK_INTERFACE:slave绑定的network接口。
· AUTO_POSITION:假诺自定定位被运用了正是1，否则是0
· SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH,
SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY,
SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH
这几个列显示了slave连接到master的SSL的参数SSL_ALLOWED的值如下：
§ Yes，如果SSL连接到master被允许。
§ No，假若SSL连接到master不被允许。
§ Ignored,如果SSL被允许，但是slave不支持SSL。
Change master to选项还有其余ssl选项：MASTE中华V_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL, MASTER_SSL_CRLPATH, MASTER_SSL_KEY, MASTER_SSL_VERIFY_SERVER_CERT。
· CONNECTION_RETRY_INTE福特ExplorerVAL:重试的秒数。
· CONNECTION_RETRY_COUNT:失误连连之后重试的次数。
· HEARTBEAT_INTE奥迪Q5VAL:复制心跳间隔。
咱俩先来看看表中记录的总括音讯是何等样子的。
1.1.5. stop slave
效益：结束slave上的复制相关线程。
语法：
STOP SLAVE [thread_types]
thread_types:
[thread_type [, thread_type] ... ]
thread_type: IO_THREAD | SQL_THREAD
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
2三.九.1四 品质框架类别状态变量表
和连串变量表类似，具体看：
根据帐号、主机名、用户名叫分组对状态变量进行分拣数据，例如：依据帐号表总计的表分组列为host和user列，聚合列当然就是状态变量本身（该效用是MySQL 5.7版本新扩大的），有如下几张表：
23.9.5.2 events_stage_history表
Events_stages_history为各类线程保留了N个记录，具体能够经过配备参数修改：
performance_schema_events_stages_history_size
-------------- --------------- ----------------- ----------------------------
2三.拾 质量框架选项和变量
具体看：
FIRST_SEEN: 2017 -12-3022 :34:51
②3.四 品质框架记录点命名约定
记录点命名是1串组件然后用‘/’分割：
wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables
记录点命名类似于树形结构。从左到右越来越详细，组件的名号以来与计数器类型。
名字由贰局地组成：
· 组件名，比如mysiam
· 变量名，1种是全局变量，还有一种是class::value。值class类中的变量。
头号记录点组件
· Idle:表示idle事件的记录点。
· Memory：memory事件记录点
· Stage：阶段事件记录点
· Statement：语句事件记录点
· Transaction:事务事件记录点
· Wait：等待事件记录点
Idle记录点组件
Idle记录点用于idle事件，具体看：二3.九.三.5 socket_instance表
内部存款和储蓄器记录点组件
洋洋内部存款和储蓄器记录点暗中认可是不可用的，能够手动运行，修改setup_instruments表。记录点前缀，memory/performance_schema/表示有个别许品质框架之中的内部存储器分配。memory/performance_schema/总是启用的，并且不能够被剥夺。那件记录点被采访在 memory_summary_global_by_event_name表。
Stage记录点组件
Stage代表语句阶段性处理的比如说sorting result也许sending data。
语句记录点组件
· Statement/abstract/*: 抽象语句操作记录点。抽象记录点在言语早期选拔。
· Statement/com :是记录点命令操作。并且有名字对应到com_xxx操作，比如statement/com/Connect 和 statement/com/Init DB对应到COM_CONNECT和COM_INIT_DB命令。
· Statement/scheduler/event：单个记录点用来追踪全数事件调度生成的风浪。
· Statement/sp ：存款和储蓄进程举行内部的记录点，比如statement/sp/cfetch 和statement/sp/freturn，用来游标获取和函数重回。
· Statement/sql:sql操作的记录点，比如statement/sql/create_db和statement/sql/select，用于成立数据库和select语句。
伺机记录点指令
· Wait/io,io操作记录点
§ Wait/io/file:文件io操作记录点，对于文本，等待是伺机文件操作文件达成。因为缓存的关联，物理文件io恐怕在这么些操作上不会试行
§ Wait/io/socket：socket操作记录点，socket记录点有以下命名格式：wait/io/socket/sql/socket_type。服务有1个监听socket用来帮衬各种网络协议。那么些记录点扶助监听socket是tcpip或许unix socket文件。socket_type的值为server_tcpip_socket或者server_unix_socket。当监听socket发现二个三番五次，服务把那么些接二连三变换来独门的线程。那么新的连年线程的socket_type为client_connection。
§ Wait/io/table: 表io操作记录点。包蕴持久性表也许一时半刻表的行等第访问。对行的震慑正是fetch，insert，update，delete。对于视图，是被视图引用的基表。和别的等待差异，表的io等待报货其余等待。比如表io或许含有，文件io只怕内部存款和储蓄器操作。由此events_waits_current中对此行的等待恐怕有2行。
· Wait/lock ,锁操作的记录点
§ Wait/lock/table,表锁记录点操作
§ Wait/lock/metadata/sql/mdl,元数据所操作
· Wait/synch,同步对象记录点
§ Wait/synch/cond,条件被用来2个线程布告其它二个线程，有些它们等待的东西已经实现。若是三个线程等待三个准绳，那么会醒来并且处理。假设多个线程等待那么会都新来并且产生它们等待的能源。
§ Wait/synch/mutex,多排他对象用来走访三个能源，幸免其余线程访问财富。
§ Wait/synch/rwlock,1个读写锁对象用来锁定特定的变量，幸免其余线程使用。1个共享读所能够三个线程同时获得。多个排他写锁只可以由三个线程获取。
§ Wait/synch/sxlock,共享排他锁是读写锁的rwlock的一种，提供当三个线程写时，其余线程能够非壹致性读。Sxlock在mysql 5.7中使用为了优化rwlock的或显示。
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-104099082
23.9.12.1 metadata_locks
属性框架把元数据锁通过metadata_locks显示。彰显一下音讯：
· 锁已经被分配
· 锁被呼吁可是未有被分配。
· 锁请求但是被死锁kill也许锁等待超时而被吊销。
这一个音信方可明白元数据锁和对话之间的涉及。能够查阅等待的锁，也能够查看已经获取的锁。
Metadata_locks表只读，不可能写入。暗中认可是自行大小的，也足以由此运行参数配置高低：performance_schema_max_metadata_locks。
表私下认可是被剥夺的，拖过设置setup_instruments的/locl/metadata/sql/mdl来启动。
性子框架爱护内容，使用lock_status表示锁的图景：
· 当元数据锁被呼吁并且及时获得，行的情事的是GRANTED。
· 当元数据锁被呼吁可是尚未即时获得，行的地方为pending。
· 当在此以前请求的元数据锁获取了，行的情状改为granted。
· 当元数据锁被假释，行被删去。
· 当pending的锁请求被死锁发现器裁撤，状态改为victim。
· 当pending的锁超时，状态变为pending to timeout。
· 当分配的锁依旧pending的锁被kill，状态成为killed。
· 当VICTIM,TIMEOUT,KILLED被布告之后行会被剔除。
· PRE_ACQUIRE_NOTIFY,POST_RELEASE_NOTIFY状态，当获得锁照旧释放锁时，lock子系统通报所在的贮存引擎的情景。
Metadata_locks列：
· OBJECT_TYPE:能够是那几个值的中间二个.
GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, T凯雷德IGGE卡宴 (currently unused),
EVENT, COMMIT, USE索罗德 LEVEL LOCK, TABLESPACE, LOCKING SE福睿斯VICE。
假使值为USE揽胜 LEVEL LOCK表示从get_lock()获取锁，假诺是LOCKING SEPRADOVICE表示使用lock service获取说。
· OBJECT_SCHEMA:对象所在的schema
· OBJECT_NAME:对象名
· OBJECT_INSTANCE_BEGIN:记录点对象在内部存储器中的地址。
· LOCK_TYPE：锁的体系，INTENTION_EXCLUSIVE, SHARED, SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE, SHARED_NO_WRITE, SHARED_NO_READ_WRITE, or EXCLUSIVE.
· LOCK_DURATION:lock持续的限制期限。能够是这几个值STATEMENT, TRANSACTION, EXPLICIT. STATEMENT 和TRANSACTION从言语或然工作的启幕直到语句或然业务的终结。
· LOCK_STATUS:锁的场地，PENDING, GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY, POST_RELEASE_NOTIFY.
· SOUCE:源代码文件中的文件名和岗位。
· OWNER_THREAD_ID：请求元数据的线程。
· OWNER_EVENT_ID:请求锁的事件id。
5 rows inset (0.01 sec)
23.9.3.3 mutex_instances表
Mutex_instances展现了具有能够被质量框架查看到的随机信号量。复信号量是1块机制用来保卫安全能源。当贰个线程运转必要放问一样的能源，1个线程会互相争用，三个线程获取了mutex上的锁，那么其余一个不得不等待上一个完结。
当任务实行获取实信号量，称为临界区域，区域内实践都以逐1的，恐怕有私人住房瓶颈问题。
表中有3个字段：
Name：记录点的名字
OBJECT_INSTANCE_BEGIN:被记录的随机信号量在内部存储器中的地址。
LOCKED_BY_THREAD_ID：拥有mutex的线程id，否则为null。
对于每一种记录的时限信号量，质量框架提供一下音信：
· Setup_instruments表列出了笔录点名，以wait/synch/mutex/为前缀。
· 当有代码创造了信号量，那么就有一行被投入到mutex_instrances表中，OBJECT_INSTANCE_BEGIN列是mutex的绝无仅有列。
· 当3个线程视图锁定复信号量，events_waits_current表为线程显示1行，表达在等待实信号量，通过object_instance_begin。
· 当线程成功锁定了一个实信号量：
§ Events_waits_current，展现等待实信号量就会达成
§ 完结的事件会被增添到历史表中
§ Mutex_instances显示随机信号量今后属于1个thread
· 当thread unlock二个时限信号量，mutex_instances呈现功率信号量今后从未有过owner，thread_id为null。
· 当非功率信号量对象被灭绝，对应的行也会被去除。
查以下二个表，能够会诊瓶颈或许死锁：
§ Events_waits_current,查看线程等待的能量信号量。
§ Mutex_instrances,查看其余线程的装有的能量信号量。
该表中记录的是从库使用八线程复制时，从库的协调器工作情景记录，当从库使用十二线程复制时，每一种通道下将创立1个体协会调器和七个干活线程，使用协调器线程来保管那一个职业线程。假如从库使用单线程，则此表为空（对应的笔录转移到replication_applier_status_by_worker表中记录），大家先来探望表中著录的总括消息是怎么体统的。
贰三.玖.壹3 质量框架种类变量表
MySQL维护了众多系统变量，系统变量在这个表是可用的：
· Global_variables：全局系统变量。如若应用程序只要全局值能够选择那几个表。
· Session_variables：当前对话的种类变量。还有未有session变量部分的global变量
· Variables_by_thread：各类会话的种类变量。
那个会话品级的变量只包涵了移动会话的变量。这一个表不扶助truncate table。
Global_variablees和session_variables表有这个列：
· VARIABLES_NAME:变量名
· VARIABLES_VALUE:变量的值。
Variables_by_thread的列：
· Thread_id:线程id
· VARIABLES_NAME:变量名
· VARIABLES_VALUE:变量的值。
Variables_by_thread表包括了后台线程的系统变量消息。借使不是有所的线程记录，那么表内有个别行会小时。那一年Performance_schema_thread_instance_lost状态变量大于0 。
| group_replication_applier |2| 93 |ON | |0| |0000- 00- 0000:00:00|
二3.玖.6 品质框架语句事件表
质量框架记录点语句推行。语句事件爆发在高端别的事件，等待事件嵌套在stage事件中，stage事件嵌套在讲话事件中，语句事件嵌套在职业事件中。
讲话事件配置
Setup_instruments表包蕴记录点，以statement前缀的记录点。那几个记录点的暗中认可值能够采纳语句：
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';
能够经过以下语句修改：
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
-> WHERE NAME LIKE 'statement/com/%';
翻看和更动timer：
mysql> SELECT * FROM setup_timers WHERE NAME = 'statement';
----------- ------------
| NAME | TIMER_NAME |
----------- ------------
| statement | NANOSECOND |
----------- ------------
修改timer:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
-> WHERE NAME = 'statement';
语句监视
语句监视起头于被呼吁的活动到全体移动截止。也正是劳务受到客户端的首先个包，到完结重返响应。在MySQL 五.柒.贰以前，语句只会是高端别的，比如在仓库储存进度照旧子查询不会被分离出来。
最后记录点名和劳动命令和sql语句关于：
· 关联到COM_xxx定义在mysql_com.h头文件和在sql/sql_parse.cc中处理，比如COM_PING和COM_QUIT,那么记录点名以statement/com起初，比如statement/com/ping和statement/com/ping。
· SQL语句是用文件表示的。那么相关的命令行以statement/sql开首，比如statement/sql/delete和statement/sql/select。
有的笔录点名表示格外的错误处理：
· Statement/com/error，记录了劳务搜集到的未绑定的消息。无法看清从客户端发送到服务端的命令。
· Statement/sql/error,记录了sql语句分析错误。用来检查判断查询发送到客户端的不得了。贰个询问分析错误和询问推行错误不一样
请求能够通过以下水道得到：
· 1个下令也许语句从客户端获取并发送
· 在replication slave，语句字符串从relay log读取。
· 从event scheduler获取事件。
恳请的详尽原来是不通晓的，并且质量框架从呼吁的相继获取一定的笔录点名。
从客户端搜罗的请求：
一. 当服务意识二个新的包在socket等第，2个新的的语句以抽象的记录点名statement/abstract/new_packet开始。
二. 当服务读取包序号，获取接受的呼吁类型，品质框架获取记录点名。比如，请求是COM_PING包，那么记录点名会变成statement/com/ping。要是请求是COM_QUE猎豹CS陆Y包，知道是三个sql语句，不过不知情具体的体系。那个时候会给二个架空的笔录点名statement/abstract/query。
三. 假设请求的言语，文本早已读入到分析器。分析今后，那么规范的言辞类型已经知晓了，固然请求是三个插入语句，质量框架会再一次定位记录点名statement/abstract/Query to statement/sql/insert。
对此从复制的relay log上读取语句：
一. 语句在relay log中是以文件存款和储蓄的。未有网络协议，所以statement/abstract /new_packet不会被应用，而是采用statement/abstract/realy_log。
二. 当语句被解析，准确的语句类型被识破。比如insert语句，那么质量框架会再一次寻找记录点名，statement/abstract/Query to statement/sql/insert。
地点介绍的，只是依照语句的复制，对于基于行的复制，订阅表行处理能够被记录，不过relay log中的行事件描述语句的并不会出现。
对于从事件调度器来的呼吁：
事件实行的笔录点名叫statement/scheduler/event。
事件体重的事件执行记录点名使用statement/sql/*，不适用其余抽象记录点名。事件是二个储存进度，并且存款和储蓄进度是预编译在内部存款和储蓄器中的。那么在施行时就不会有分析，不过项目在实行时就知晓了。
在事变体内的语句都是子句。比如1个事件实践了1个insert语句，施行的风浪是上面。记录点使用statement/scheduler/event，并且insert是下边，使用statement/sql/insert记录点。
如此不单单是要开动statement/sql/*记录点，还要运转statement/abstract/*记录点。
在以前的5.7本子的，抽象记录点名用其余记录点代替的：
· Statement/abstract/new_packet之前为statement/com/
· Statement/abstract/query之前为statement/com/Query
· Statement/abstract/relay_log之前为statement/rpl/relay_log
-------------- ----------- ----------- --------------- ----------------------- ------------------- -------------------- ----------------------
2三.玖.壹伍 品质框架总计表
等候事件总计表：
· Events_waits_summary_global_by_event_name：等待事件依据各类事件举办商谈。
· Events_waits_summary_by_instance：等待事件依据各种instance实行总结。
· Events_waits_summary_by_thread_by_event_name：依据线程和事件名合计的表。
Stage统计表：
· Events_stages_summary_by_thread_by_event_name：stage等待和线程id总结的表。
· Events_stages_summary_global_by_eevnt_name：stage等待中每一个事件名的总结表。
语句计算表：
· Events_statements_summary_by_digest：各种schema和digest后的总结表。
· Events_statements_summary_by_thread_by_event_name：语句事件名和线程的总括表。
· Events_statements_summary_global_by_event_name:每一种语句事件名的总括表。
· Events_statements_summary_by_program：每一个存款和储蓄程序的总括(存款和储蓄进度和储存函数)。
· Prepared_statements_instances：预备的言辞实例和计算消息。
事务计算表：
· Events_transactions_summary_by_account_by_event_name：每种账号发起的轩然大波总结。
· Events_transactions_summary_by_host_by_event_name：每一种host发起的业务事件总括。
· Events_transactions_summary_by_thread_by_event_name:每一个线程发起的事体育赛事件总结。
· Events_transactions_summary_by_user_by_event_name:每一种用户发起的作业事件总结。
· Events_transactions_summary_global_by_event_name：事务事件名总括。
对象等待总计：
· Objects_summary_global_by_type：对象合计。
文件IO统计：
· File_summary_by_event_name：合计具备文件io事件名。
· File_summary_by_instance：各样文件实例的商议。
表IO和锁等待总结：
· Table_io_waits_summary_by_index_usage：每一个具有的表io等待。
· Table_io_waits_summary_by_table:每一个表的io等待。
· Table_io_waits_summary_by_table:种种表的锁等待。
总是总结：
· Events_waits_summary_by_account_by_event_name：每种账号发起的等候事件总计。
· Events_waits_summary_by_user_by_event_name：各类用户发起的等待事件计算。
· Events_waits_summary_by_host_by_event_name:每一个host发起的守候事件合计。
· Events_stages_summary_by_account_by_event_name：各种账号stage事件总括。
· Events_stages_summary_by_user_by_event_nam:各类用户发起的stage事件总计。
· Events_stages_summary_by_ host_by_event_name:每一个host发起的stage事件合计。
· Events_statements_summary_by_digest：每种schema下的保有digest。
· Events_statements_summary_account_by_event_name:各个账号发起的讲话事件。
· Events_statements_summary_by_user_by_event_name:每种用户发起的口舌事件。
· Events_statements_summary_host_by_event_name：每一种host发起的说话事件。
Socket统计：
· Socket_summary_by_instance：各类实例的socket等待和io合计。
· Socket_summary_by_event_name:socket等待和io合计。
内部存款和储蓄器总括:
· Memory_summary_global_by_event_name：内部存储器操作事件合计。
· Memory_summary_by_thead_by_event_name：每种线程内部存款和储蓄器操作合计。
· Memory_summary_by_account_by_event_name:各样账号内部存款和储蓄器操作合计。
· Memory_summary_by_user_by_event_name:每个用户内部存款和储蓄器操作合计。
· Memory_summary_by_host_by_event_name:各类host内部存款和储蓄器操作家协会议。
状态变量总结：
· Status_by_account：状态变量账号合计。
· Status_by_host：状态变量host合计
· Status_by_user:状态变量用户协议
SERVICE_STATE: ON
二三.17 迁移到质量框架体系和情状变量表
Information_schema有表包括了系统和状态变量消息，MySQL 5.7.陆后头，质量框架也含有了系统变量和状态变量消息。质量框架的表会取代information_schema上的表。
在mysql 5.6翻看状态变量和类别变量来自于：
SHOW VARIABLES
SHOW STATUS
INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES
INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS
Mysql 五.七.六，质量框架也带有了系统变量和状态变量：
performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread
performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user
MySQL 5.7.6增加了show_compatibility_5陆系统变量，如若为on：
· 当从information_schema中输出，相会世警示。
· 在mysql 5.7.6，使用show的where语句就会警告。MySQL 五.7.八自此就不会。
当变量为off，不运转包容方式:
· 搜索information_schema表会报错。
· Show语句输出的数额来至于品质框架表。
· 这些slave_XXX的状态变量不可用:
Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running
应该从性质框架的复制相关的表中获取数据。
搬迁和权力
做客质量框架中的系统变量和状态变量供给select权限。就算show_compatibility_5陆为off，那么show variables和show status也亟需select权限，假诺包容性关闭，那些语句输出来至于质量框架的global_variables,session_variables,global_status, session_status表。
在mysql 5.7.玖，这几个表在性质矿建中访问不必要select权限。对应的show variables和show status也不必要权限。
此后的公布，information_schema变量表和show_compatibility_5陆会被去除，show输出基于性能框架表。
Reference Manual] 贰叁 Performance Schema结构，manualschema 二叁 MySQL Performance Schema 贰3 MySQL Performance Schema .. 1 贰三.1 品质框架急迅运转 ... 三 贰3.二品质框架...
----------- ----------------------------------------- ----------------
二3.二.二 质量框架运转配置
假定质量框架是可用的，那么暗中同意是运营的也得以在配备文件中配置：
[mysqld]
performance_schema=ON
万一服务无法在伊始化品质框架的时候分配内部缓存，那么品质框架本身关闭并且安装performance_schema为off，服务在未有记录点处境下运转。
个性框架能够以命令行参数格局地署。
--performance-schema-instrument='instrument_name=value'
关闭全部记录点：
--performance-schema-instrument='%=OFF'
正如长的笔录点名会比短的积攒点名要先期于短的格局名，不管顺序。
切实能够看前面章节：二三.贰.三.四命名记录点或许消费者的过滤
3个不能别识别的记录点名会被忽视。为了调控消费者，可以行使以下选项：
--performance-schema-consumer-consumer_name=value
consumer_name是三个消费者名比如events_waits_history，value是以下七个值：
l OFF，False或许0：不采访这么些消费者的轩然大波
l ON,True大概壹：搜聚顾客的风云
例如消费者名是events_waits_history：
--performance-schema-consumer-events-waits-history=ON
被允许的买主名能够在setup_consumers表上找到。在表中消费者名字都是下划线，在挑选配置的时候，下划线和减号未有不相同。
属性框架提供了累累系统变量能够用来安顿：
mysql> SHOW VARIABLES LIKE 'perf%';
-------------------------------------------------------- ---------
| Variable_name | Value |
-------------------------------------------------------- ---------
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 200 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
...
Performance_Schema代表了品质框架是不是运转，别的参数表示表的大小伙内部存款和储蓄器分配的值。
能够应用安插文件开设置这一个变量：
[mysqld]
performance_schema
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000
假设未有点名值，那么默许这个变量会有1个私下认可值。在MySQL 伍.7.陆，品质框架分配内部存储器会依据劳动符合增添伙子减弱，而不是在服务运转的时候一遍性分配完了。所以重重参数并不需求在开发银行的时候都分配好，越来越多内容能够看2叁.1二品质框架连串变量。
每一个机关分配的参数不是在启动时设置也许安装为-一，品质框架决定哪些依照以下的参数来设置那一个值：
max_connections
open_files_limit
table_definition_cache
table_open_cache
如若要覆盖机关安装的值只怕电动范围的值，就在运转的时候设置八个加以的值而不是给-一那样质量框架就会安装一个加以的值。
在运作时，show variables会展现自动安装的值，自动范围设置的会给-一.倘若品质框架被禁止使用，自动安装和机动范围参数都会被设置为-一，并且展现为-壹.
1 rowinset(0 .00sec)
23.9.4.1 events_waits_current表
Events_waits_current表包蕴了近期的等候时间，每种thread都有一行展现当前thread的等待时间。伊芙nts_waits_current表能够利用truncate table。
Events_waits_current表列：
· THREAD_ID,EVENT_ID
线程相关的事件和线程当前事件号。那三个字段产生主键来标示壹行。
· END_EVENT_ID
当事件运行，这么些列为null，假设时间停止分配三个事件号。
· EVENT_NAME
浮动事件的笔录点名。
· SOURCE
源代码文件名包蕴产闹事件的记录点代码地方。可以扶持用来检查源代码。
· TIMER_START,TIMER_END,TIMER_WAIT
事件的timing音信。时间单位为微秒。TIMEHaval_START,TIMER_END表示事件的开始和得了。TIMEBMWX三_WAIT是事件的持续时间。如若事件尚无形成TIME奥迪Q伍_END,TIMER_WAIT为null。如若记录点的timed=no那么这些列都以null。
· SPINS
对此实信号量，是只自旋次数。即便为null，表示代码不行使自旋只怕自旋未有被记录。
·
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE_OBJECT_INSTANCE_BEGIN
那些列表示对象被运行的职分，依据目的类型分化含义分化：
对于联合对象：(cond,mutex,rwlock)
§ OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE为null
§ OBJECT_INSTANCE_BEGIN为一齐对象在内存中的地址。
对此文本io对象
§ OBJECT_SCHEMA为null
§ OBJECT_NAME为文件名
§ OBJECT_TYPE为file
§ OBJECT_INSTANCE_BEGIN为内部存款和储蓄器地址
对于socket对象
§ OBJECT_NAME为IP：PORT
§ OBJECT_INSTANCE_BEGIN为内部存款和储蓄器地址
对于表io对象
§ OBJECT_SCHEMA是表所在schema的名字
§ OBJECT_NAME表名
§ OBJECT_TYPE为table或者temporary table
§ OBJECT_INSTANCE_BEGIN是内部存款和储蓄器地址
OBJECT_INSTANCE_BEGIN本人是平素不意义的，除非分歧的值表示差别的对象。OBJECT_INSTANCE_BEGIN能够用来调控。比如group by那些字段查看是或不是有一千个非确定性信号量，形成有些瓶颈。
· INDEX_NAME
行使的index名字，primary表示表的主键索引，null表示一直不索引
· NESTING_EVENT_ID
event_id表示充足event被嵌套
· NESTING_EVENT_TYPE
嵌套的事件培养和磨炼，恐怕是以下壹种，TRANSACTION,STATEMENT,STAGE,WAIT
· OPERATION
推行操作的体系，lock，read，write中一个。
· NUMBER_OF_BYTES
读写操作的字节个数。对于表io等待，MySQL 5.七.5从前值为null，之后为行数。假如值高出一，是批量io操作。MySQL实行join是nested-loop机制。质量框架能够提供行数和各类表实行join准确的日子。要是1个join查询，实践如下：
SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
在join操作的时候表的表行的扩展减弱(扇出)。假若t三的扇出抢先1，那么大繁多行获得操作就出自于那几个表。假诺t一 十行，t2 20行对应到t11行，t三 30行对应t二 一行。那么一共会有被记录的操作是：
10 (10 * 20) (10 * 20 * 30) = 6210
为了削减被记录操作，能够因此每一趟扫描完结聚合的不2秘籍(聚合t壹,t二的绝无仅有值)。记录点计数减弱为：
10 (10 * 20) (10 * 20) = 410
对此地方的事态使用环境：
§ 查询访问的表基本上都是inner join的
§ 查询实施不要求表内的单个记录
§ 查询实行不要求评估子查询访问了表。
· FLAGS
保留
MEMBER_ID: 5d78a458-30d2-11e8-a66f-5254002a54f2
贰三.二.三.五 识别哪些已经被记录
因而检查setup_instruments表，你能够查出包罗了何等记录点被记录：
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/file/innodb/%';
-------------------------------------- --------- -------
| NAME | ENABLED | TIMED |
-------------------------------------- --------- -------
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
-------------------------------------- --------- -------
COUNT_AUTH_PLUGIN_ERRORS: 0
23.9.2.5 setup_timers表
Setup_times表如下：
mysql> SELECT * FROM setup_timers;
------------- -------------
| NAME | TIMER_NAME |
------------- -------------
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
------------- -------------
Timer_name是，performance_timers中的一行。表示有些事件类型应用了什么样计时器
- 此表提供了全部线程binlog重播事务时的日常状态新闻。线程回看事务时特定的动静消息保存在replication_applier_status_by_coordinator表（单线程复制时该表为空）和replication_applier_status_by_worker表（单线程复制时表中著录的消息与多线程复制时的replication_applier_status_by_coordinator表中的记录类似）
贰三.二.3.三 事件预过滤
预过滤有品质框架产生同时会全局的熏陶全体用户。预过滤能够在劳动者大概消费者的处理阶段上：
· 多少个表能够用来布局生产者的预过滤：
§ Setup_instruments表达哪个记录点是可用的，假诺那个表上一个记录点被禁止使用，不管其余表怎么安排，都不会再产惹祸件。
§ Setup_objects调控了品质框架特定表和存储进度对象。
§ Threads表示是还是不是各类服务线程都有监察和控制
§ Setup_actors新的后台进度的始发监察和控制情况
· 要配置预过滤在消费者阶段，那么要修改setup_comsumers表。setup_comsumers也会影响事件的发生。假使钦定的风云不会发送给任哪个地方方，那么品质框架不会生出
修改任意表都会及时影响监察和控制，不过有个别差别：
· 修改有个别setup_instruments表唯有的服务运营的时候生效。在运作时修改不会生效。
· 修改setup_actors表，只会影响后台线程。
当修改监察和控制配置，品质框架不会刷新历史表。历史表和近日表的轩然大波不会被交换，除非又新的事件。假使禁止使用三个记录点的时候，需求静观其变一段时间，来替换老的风浪。也得以用truncate table清空。
在修改完记录点之后，恐怕下十二分药伤处summary表清理总计新闻对于events_statements_summary_by_digest大概内存总括表。Truncate table只会重新恢复设置值为0，并不会删除行。
- global_status：全局状态变量。如若只须要全局状态变量值的应用程序能够查询此表，中断的对话状态变量值会被集结在此表中
- session_status：当前对话的状态变量。要是只盼望查询自身对话的具有情状变量值的应用程序可以查询此表（注意：该表包涵未有对话级其余全局状态变量），只记录活跃会话，不记录已暂停的对话
- status_by_thread：根据线程ID作为标志符记录每种活跃会话的状态变量。若是急需在某些会话中查询其余会话的情景变量值能够查询此表（注意：该表不带有只持有全局品级的状态变量），只记录活跃会话，不记录中断的对话
23.9.12.2 table_handles
通过表table_handles重回表锁音信。Table_handle显示了种种张开表的handle的锁音信。那三个表被张开了，怎样被锁定的，是哪个线程锁的。
Table_handles是只读表，不可能修改，表列如下：
· OBJECT_TYPE:被table handle展开的表。
· OBJECT_SCHEMA:表所在的schema。
· OBJECT_NAME:记录点对象名。
· OBJECT_INSTANCE_BEGIN:记录点对象在内部存款和储蓄器中的地址。
· OWNER_THREAD_ID：请求元数据的线程。
· OWNER_EVENT_ID:请求锁的风浪id。
· INTERNAL_LOCK:SQL等第使用的表锁。值如下: READ, READ WITH SHARED LOCKS, READ HIGH P瑞虎IO帕杰罗ITY, READ NO INSERT, WOdysseyITE ALLOW W昂科拉ITE, W奇骏ITE CONCUMuranoRENT INSERT, WRAV四ITE LOW P哈弗IO奥迪Q7ITY, W福特ExplorerITE。
· EXTERNAL_LOCK：存款和储蓄引擎品级使用的表锁，READ EXTE哈弗NAL ,W宝马X3ITE EXTERubiconNAL
|Aborted_clients | 0 |
二三.二.三.一 质量架构事件定期
事件被采访也正是说记录点被加到了服务源代码中。记录点时间事件，是性质框架怎么样提供1个轩然大波不断多长时间的方案。也能够布署记录点搜聚定期消息。
属性框架定时器
叁个天性框架表提供了定期器音信：
l Performance_timers，保存了可用的timers和它们的表征。
l Setup_timers，表明了怎么样记录点使用了哪些timers。
每个setup_timers使用的计时器躲在performance_timers表中。
mysql> SELECT * FROM performance_timers;
------------- ----------------- ------------------ ----------------
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
------------- ----------------- ------------------ ----------------
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | 1000000000 | 1 | 112 |
| MICROSECOND | 1000000 | 1 | 136 |
| MILLISECOND | 1036 | 1 | 168 |
| TICK | 105 | 1 | 2416 |
------------- ----------------- ------------------ ----------------
TIMER_NAME：表示可用timer的名字，CYCLE表示给予cpu计数器
TIMER_FREQUENCY:表示每秒的timer个数。对于cycle timer，频率和cpu事件相关，别的timer是秒的多少分。
TIMER_RESOLUTION：表示每趟扩张的单位
TIMER_OVELANDHEAD:钦命周期获取一个定期须要的十分小cycles个数。每一种事件都会在上马和终结的时候调用timer，因而是展示的负载的二倍。
修改setup_timer表的timer_name：
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
-> WHERE NAME = 'idle';
mysql> SELECT * FROM setup_timers;
------------- -------------
| NAME | TIMER_NAME |
------------- -------------
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
------------- -------------
暗中同意性能框架会为每一个记录点类型设置timer，也得以修改。
对此记录等待事件的时辰，最根本的是在时光精度上减小负荷，所以选择cycle timer最合适。
对此讲话或许stage的施行比进行3个简练的守候要大的多，并且必要二个准确的量，并且和电脑非亲非故，所以最佳不用采取cycle。暗中同意使用NANOSECOND。固然负荷比cycle要大，可是不重要，因为调用3次计数器的多少级远远比试行语句小编的cpu时间要小。
Cycle提供的精度和cpu有关，假如处理器是1Gh依然更加高，cycle能够提供比飞秒还小的进程。使用cycle计数器比得到一个一天的实际上事件支出小。
Cycle的缺点：
l 从cycles转化为时间单位是相比较麻烦的。为了越来越快，这一个转化操作知识非常的粗糙的乘法总计。
l 处理器cycle，大概会遍，比如台式机进入省电形式，那么cpu cycle会下跌要是cpu cycle有变乱，那么转化就会出错。
l Cycle 计数器恐怕是不可信的依然不可用的，和处理器可能操作系统有关。
l 1些处理器，乱序施行可能多处理器同步，恐怕会促成计数器忽高忽低。
质量框架计数器在事变中的表现
存款和储蓄在品质框架表的近期事件，有一个列表示事件，TIMEBMWX三_START,TIMER_END代表事件运维和竣事，TIMEBMWX五_WAIT代表事件的小时。
Set_instruments表有ENABLED字段来代表，事件是不是要搜罗。TIMED字段表示记录点是不是被时光标志。要是记录点未有运营，那么就不会转换事件。假设不是timed,那么生成的风浪，中TIMELAND_START,TIME_END,TIMER_WAIT是null。那么在总计表总计最大日子，最小时间的时候会被忽视。
在那之中，事件运营的时候，timer以给定的单位保存在事变之中，当要展现的时候，timers被突显为正规的事件单位，不管选了怎样timer都会显得为，阿秒。
Setup_timers的修改会即时见效。已经在处理的会动用老的timer。为了不产生不能够预料的结果出现，最棒先把计算表使用truncate table进行重新恢复设置。
Timer的基线，在服务运行的时候被开头化。TIME福特Explorer_START,TIMER_END表示从基线以来的阿秒数。TIMETiggo_WAIT表示占用的微秒。
5. replication_connection_configuration表
贰三.8 质量框架常用表天性
Performance_schema数据库是小写的，数据Curry面包车型地铁表名也是小写的。查询要使用小写。
多数表在performance_schema数据库是只读的不能被更动。一些setup表的某个列能够被退换。一些也足以被插入和删除。事务能够被允许清理搜罗的事件，所以truncate table可以用来清理音信。
Truncate table能够在总计表上选择，不过不可能再events_statements_summary_by_digest和内部存款和储蓄器总计表上利用，效果只是把一同列清理为0.
|| 0 |
2三.二.三.三.一 记录点预过滤
决定记录点的过滤，是过滤setup_instruments表设置enables字段。修改setup_instruments大多数会立时见效。对于有个别记录点，修改只会在服务器运维才会卓有功效。setup_instruments提供了最主题的记录点调控。
| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |
二三.7 品质框架statement digests
MySQL服务有技术保险statement digest消息。Digest进程把一个sql语句转化为正规的格式并且总括三个hash结果。标准化允许相似的言辞分组并且总计暴光1些说话的档次和产生的频率。
在品质框架，语句digest涉及那一个零件：
· Setup_comsumers的statement_digset调控了，品质框架如何保护digest消息。
· 语句事件表有列包罗digest和相关的值的列：
§ DIGEST_TEXT，标准化的言辞。
§ DIGEST,是digest MD5 hash值。
Digest总计，最大的可用空间102四B。MySQL 伍.七.8后这些值能够由此参数，performance_schema_max_digest_length修改。在此以前使用max_digest_length。
· 语句事件表也有sql_text列包罗了本来面指标sql语句。语句展现的最大为拾2四B，能够通过performance_schema_max_sql_text_length字段修改。
· events_statements_summary_by_digest，提供综合的语句digset音信。
规则2个口舌转化，会保留语句结构，删除不要求的音讯：
· 对象标志符，比如表大概数据库名会被保存。
· 文本值会被替换到变量。
· 注释会被删除，空格会被调动。
比如说如下一个语句：
SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100
轮换后会产生：
SELECT * FROM orders WHERE customer_id = ? AND quantity > ?
对于每一个标准化的说话提供一个DIGEST_TEXT和DIGEST1个hash值。语句Digest总括表，提供了言语的profile消息，突显语句运营功用运转次数等。
events_statements_summary_by_digest大小固定的，所以只要满了，借使在表上未有相称的，那么全部的语句都会被总结在schema_name和digest为null的记录里面，当然能够追加digest大小，performance_schema_digests_size，假设未有点名，那么质量框架会融洽评估一个值。
performance_schema_max_digest_length系统变量支配digest buffer最大可用字节。然则现实的语句digest的长短往往比buffer长，那是因为根本字和文本值的涉嫌。也正是说digest_text的长度大概超过performance_schema_max_digest_length。
对此应用程序生成了相当长的话语，只有最后不一致，扩张performance_schema_max_digest_length能够让digest得以计算，识别语句。反过来收缩performance_schema_max_digest_length会导致服务捐躯很少的内存来保存语句的digest，可是扩充了言语的相似度，被当成同一个digest。假设长度须要长，那么保存的也要更多。
能够透过show engine performance_schema status语句，可能监察之下语句查看sql语句保存使用的内部存款和储蓄器量。
mysql> SELECT NAME FROM setup_instruments
-> WHERE NAME LIKE '%.sqltext';
------------------------------------------------------------------
| NAME |
------------------------------------------------------------------
| memory/performance_schema/events_statements_history.sqltext |
| memory/performance_schema/events_statements_current.sqltext |
| memory/performance_schema/events_statements_history_long.sqltext |
------------------------------------------------------------------
mysql> SELECT NAME FROM setup_instruments
-> WHERE NAME LIKE 'memory/performance_schema/%.tokens';
----------------------------------------------------------------------
| NAME |
----------------------------------------------------------------------
| memory/performance_schema/events_statements_history.tokens |
| memory/performance_schema/events_statements_current.tokens |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens |
----------------------------------------------------------------------
---------------------------- ---------------
23.玖.1陆 质量框架其余表
除此而外上边你的表还有一个表：
· Host_cache：内部host cache信息。
· Performance_timers:事件可用定期器。
· Threads:服务的线程表。
| admin |localhost | Bytes_sent |305705|
贰三.玖.伍 品质框架Stage事件表
质量框架stage记录，是语句实践的等第，比如解析语句，张开表大概推行filesort操作。Stage关联到的了show processlist中的线程状态。
因为事件品级，等待事件穿插在stage事件，stage事件穿插在语句事件，事务事件。
Stage事件配置
开行stage事件的募集，运转相应的记录点和消费者。
Setup_instruments表包涵以stage开端的记录点名。那一个记录点除了说话处理的音信，暗中认可是禁止使用的：
mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]';
---------------------------------------------------- --------- -------
| NAME | ENABLED | TIMED |
---------------------------------------------------- --------- -------
| stage/sql/After create | NO | NO |
| stage/sql/allocating local table | NO | NO |
| stage/sql/altering table | NO | NO |
| stage/sql/committing alter table to storage engine | NO | NO |
| stage/sql/Changing master | NO | NO |
| stage/sql/Checking master version | NO | NO |
| stage/sql/checking permissions | NO | NO |
| stage/sql/checking privileges on cached query | NO | NO |
| stage/sql/checking query cache for query | NO | NO |
| stage/sql/cleaning up | NO | NO |
| stage/sql/closing tables | NO | NO |
| stage/sql/Connecting to master | NO | NO |
| stage/sql/converting HEAP to MyISAM | NO | NO |
| stage/sql/Copying to group table | NO | NO |
| stage/sql/Copying to tmp table | NO | NO |
| stage/sql/copy to tmp table | NO | NO |
| stage/sql/Creating sort index | NO | NO |
| stage/sql/creating table | NO | NO |
| stage/sql/Creating tmp table | NO | NO |
---------------------------------------------------- --------- -------
修改stage事件，修改enabled和timing列：
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
-> WHERE NAME = 'stage/sql/altering table';
Setup_consumers表包括消费者只涉及的风云表名。消费者大概用来过滤搜罗器stage事件。Stage消费者默许禁止使用：
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';
---------------------------- ---------
| NAME | ENABLED |
---------------------------- ---------
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
---------------------------- ---------
运维全体的stage事件：
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
-> WHERE NAME LIKE '%stages%';
Setup_timers包含name=‘stage’，说明stage事件timing：
mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';
------- ------------
| NAME | TIMER_NAME |
------- ------------
| stage | NANOSECOND |
------- ------------
修改timing值：
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
-> WHERE NAME = 'stage';
Stage事件进度消息
MySQL 伍.柒.五，品质架构stage事件表包蕴2列，每行提供stage进度标示：
· WORK_COMPLETED:stage工作单元达成个数。
· WORK_ESTIMATED:预期的stage工作单元达成个数。
假如未有进程新闻，每列都以null。品质框架提供三个器皿来存放这几个进程数据：
· 工作单元，是3个量，随着奉行时间的加码变大。
· WORK_COMPLETED，一个依然七个单元扩展三回，依赖于被记录代码
· WORK_ESTIMATED,能够在stage司改，遵照，被记录代码。
对于stage事件的进程的笔录能够兑现以下任何表现：
· 未有进度记录点
以此是最常出现的，因为未有进程数据被提供，WOQX56K_COMPLETED和WORKESTIMATED都为bull
· 未有被绑定记录点
只有WORK_COMPLETED列有意义，WOOdysseyK_ESTIMATED列没有值，呈现为0。
打开events_stages_current表监察和控制回话，监察和控制程序能够告诉有些许work已经被实践，然而不清楚哪些时候能够甘休，因为记录点未有提供。
· 绑定进程记录点
WORK_COMPLETED和WORK_ESTIMATED列都是有含义的。
进程标记符的类型适合于已经定义了完毕临界的操作，比如表复制记录点。通过查询events_stages_current表来监督会话，监察和控制程序能够监控全部达成比例的stage，通过总结WO安德拉K_COMPLETED / WORK_ESTIMATED的比率。
stage/sql/copy to tmp table演示，进程标记符怎么做事。在试行alter table语句，那个记录点就很有用，并且会进行非常长一段时间。
1row inset ( 0. 00sec)
23.9.3.1 cond_instances表
Cond_instance表列出了全数质量框架能够查看的原则。条件是联合机制，用来公告一个点名的风云早已发生完成。所以1个线程等待这么些标准的会立刻复苏工作。
当1个线程等待的事物已经更改，条件名值说明线程在等候条件名。
variables_by_thread表字段含义如下：
②三.1陆 使用品质框架会诊
品质框架能够让dba来做1些本性调控，比如3个双重出现的性能难点:
一.运维用例
2.使用品质框架表，分析根本的性质难题。分析严重注重于post过滤。
三.题目区域曾经划出，禁用对应的记录点。比如尽管条分缕析出和文书io不相关，禁止使用io的记录点。
四.重复 步骤1-3，那样能够减掉苦恼寻找真正的标题。
5.显著了质量瓶颈的由来：
§ 调节服务参数
§ 调控查询。
§ 调节数据库结构
§ 调节代码。
陆.再度步骤一，查看对质量的熏陶。
在品质调优的时候，mutex_instances.locked_by_thread_id，rwlock_instances. write_locked_by_thread_id列充裕生死攸关。比如：
1.线程1，在等候三个复信号量。
2.得以应用以下语句查看等待的功率信号量：
SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;
3.然后翻看那个线程持有着这么些实信号量:
SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
4.查看线程贰在做什么样：
SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;
*************************** 2. row ***************************
23.9.4.3 events_waits_history_long 表
Events_waits_history_long表每一个线程包罗了近年来N条数据。表结构和events_waits_current壹行，也足以被truncate table，N是服务运维自动安装的，也得以从参数设置: performance_schema_events_waits_history_long_size。
COUNT_PROXY_USER_ACL_ERRORS: 0
2叁.2.三.三.4 消费者预过滤
Setup_cunsumers表包括了具有的消费者。修改这么些表来过滤这个event会被发送。
Setup_consumers表中装置消费者，从高档到低等。首要的规则如下：
· 除非品质框架检查消费者，并且消费者是可用的，不然不会受到音讯。
· 唯有当顾客重视的享有的主顾都可用了，才会被检查
· 被注重的顾客，有谈得来的依靠消费者。
· 若是3个事件未有指标，那么品质框架不会被产生。
大局和线程消费者
· Global_instrumentation是高等消费者，假若global_instrumentation为no，那么富有的的全局记录点都被剥夺。全数其余低档的都不会被检查。当global_instrumentation运维了，才会去反省thread_instrumentation
· Thread_instrumentation，要是是no，那么那几个等第下边包车型大巴品级都不会被检查，假若是yes，品质框架就会爱惜线程钦赐信息，并且检查events_xxx_current消费者。
Wait Event消费者
这一个消费者，要求global_instrumentation,thread_instrumention为yes。借使被检查行为如下：
· Events_waits_current，如若为no，禁止使用对种种wait event收罗。假诺为yes检查history消费者和history_long消费者。
· Events_waits_history，假使上级为no不检查，为yes，收罗种种等待事件。
· Events_waits_history_long,和地方类似
Stage event，statement event和地点类似。
------- ------------------------- ----------------
二3.二.三.二 质量框架事件过滤
事件是以生产者消费者情势处理的：
l 记录点代码是事件的源，产惹祸件被用来采访，setup_instruments表列出了足以被采访的记录点。Setup_instruments表提供了诸多event的发出。
l 品质框架表示事件的指标地。Setup_consumers，列出了装有消费者类型。
l 预过滤，通过修改品质框架配置完毕，可以由此启用只怕剥夺记录点和顾客达成。使用预过滤的指标：
n 减弱负荷。品质框架运行供给成本能源，固然很少。
n 不关切的轩然大波能够不写入消费者中。
n 制止维护多个类型的事件表。
· 事后过滤，能够选取where语句在询问品质框架的时候过滤。
LAST _ERROR_MESSAGE:
2三.玖.12 品质框架锁相关表
PS2：对于组复制架构，组复制的监督检查音信传布在如下几张表中
二三.三 品质框架查询
预过滤限制了怎么着事件音信被采访，许多用户都区别。能够通过select过滤event。
mysql> SELECT THREAD_ID, NUMBER_OF_BYTES
-> FROM events_waits_history
-> WHERE EVENT_NAME LIKE 'wait/io/file/%'
-> AND NUMBER_OF_BYTES IS NOT NULL;
----------- -----------------
| THREAD_ID | NUMBER_OF_BYTES |
----------- -----------------
| 11 | 66 |
| 11 | 47 |
| 11 | 139 |
| 5 | 24 |
| 5 | 834 |
----------- -----------------
- global_variables：全局系统变量。只需求全局系统变量值的应用程序能够从该表中赢得
- session_variables：当前对话的系统变量。只须要得到本人近年来对话的系统变量值能够从该表中得到（注意，该表中涵盖了无会话品级的全局变量值，且该表不记录已断开连接的系统变量）
- variables_by_thread：遵照线程ID为标志符记录的对话系统变量。想要在此时此刻线程中询问任何钦点线程ID的对话等级系统变量时，应用程序能够从该表中收获（注意，该表中仅包括有对话等级的系统变量）
二3.玖.二 质量框架setup表
Setup表提供有关当前搜罗点启用新闻。使用表而不是全局变量提供了更加高等其余性质框架配置。比如您能够运用3个sql语句配置多少个记录点。
这么些setup表示可用的：
· Setup_actors:怎么样初叶化后台线程
· Setup_consumers:决定怎样音信会被发送和存款和储蓄。
· Setup_instruments：记录点对象，哪些事件要被采访。
· Setup_objects:哪些对象要被监察和控制
· Setup_timers:当前事件定时器。
普通，DBA或有关数据库运行职员在查看从库的复制相关的音讯，都习惯性的使用show slave status语句查看。恐怕你会说，作者也会用performance_schema下的表查看有的复制报错音讯什么的。然则，你了解show slave status语句、mysql系统库下的复制音讯记录表、performance_schema系统库下的复制音讯记录表之间有哪些分别呢？不知晓？别急，本文将要为你详细介绍show slave status语句与performance_schema系统库下的复制音讯记录表的区分（mysql系统库下的复制表不同详见后续 "mysql系统库全方位介绍"体系）。
23.9.2.1 setup_actors表
setup_actors表包蕴了音讯决定是不是监察和控制大概对新的后台线程进行历史数据记录。那几个表暗中同意最多十0行，能够通过退换参数performance_schema_setup_actors_size修改尺寸。
对此新的后台线程，在setup_actors中，品质框架满意的用户和host。倘使二个行负荷enabled，histroy列，对应到threads表上的instrumented和history列。如若找不到十三分那么instrumented和history列就为no。
对于后台线程， Instrumented和history暗中同意都以yes，setup_actors暗中认可未有限定。
Setup_actors先河化内容，可是滤任何数据：
mysql> SELECT * FROM setup_actors;
------ ------ ------ --------- ---------
| HOST | USER | ROLE | ENABLED | HISTORY |
------ ------ ------ --------- ---------
| % | % | % | YES | YES |
------ ------ ------ --------- ---------
修改setup_actors表只会影响后台线程，不会影响已经存在的线程。为了影响已经存在的threads表，修改instrumented和history列。
表中各字段含义如下：
二三.陆 品质框架和分子原子性事件
对此一个表的io事件，平日有二行在events_waits_current，不是二个如：
Row# EVENT_NAME TIMER_START TIMER_END
---- ---------- ----------- ---------
1 wait/io/file/myisam/dfile 10001 10002
2 wait/io/table/sql/handler 10000 NULL
行获得会招致文件读取。比如，表io获取事件在文件io事件在此以前，可是还平昔不成功。那么文件io嵌入在表io事件。
和任何原子性等待事件分化，表io事件是成员，包罗其余事件。伊芙nts_waits_current中，表io事件无独有偶有二行：
· 1行是时下表io等待事件
· 1行是别的任何项指标守候事件。
常备，别的项指标等候事件不是表io事件。当副事件做到，会从events_waits_current中消失。
该表中记录从库线程延迟复制的安顿参数（延迟复制的线程被誉为普通线程，比如CHANNEL_NAME和DESIRED_DELAY字段记录有个别复制通道是不是须求实行延迟复制，假使是MG智跑集群，则记录组复制从节点的推移复制配置参数），该表中的记录在Server运行时得以使用CHANGE MASTER TO语句进行改动，大家先来看望表中著录的总结音讯是怎样样子的。
贰3.1三 品质框架状态变量
具体看：
依据帐号、主机、用户总括的状态变量总括表
二三.1一 质量框架命令选项
具体看：
|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |
二3.九.柒 质量框架事务表
性子框架事务记录点。在事变等级，等待事件嵌套stage事件，stage事件嵌套语句事件，语句事件嵌套事务事件。
作业事件配置
Setup_instruments包涵的transaction的记录点：
mysql> SELECT * FROM setup_instruments WHERE NAME = 'transaction';
------------- --------- -------
| NAME | ENABLED | TIMED |
------------- --------- -------
| transaction | NO | NO |
------------- --------- -------
开头搜罗职业事件：
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
-> WHERE NAME = 'transaction';
Setup_consumers表包涵transaction的消费者：
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%transactions%';
---------------------------------- ---------
| NAME | ENABLED |
---------------------------------- ---------
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
---------------------------------- ---------
初阶消费者：
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
-> WHERE NAME LIKE '%transactions%';
安装相关记录点：
mysql> SELECT * FROM setup_timers WHERE NAME = 'transaction';
------------- ------------
| NAME | TIMER_NAME |
------------- ------------
| transaction | NANOSECOND |
------------- ------------
修改timer_name的值：
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
-> WHERE NAME = 'transaction';
职业绑定
在MySQL Server，使用以下语句展现运维工作：
START TRANSACTION | BEGIN | XA START | XA BEGIN
政工也能够隐式运行，当autocommit系统变量运转。当autocommit禁止使用，在起步新业务钱要来得的终结上边一个业务。
COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK
实施DDL语句，事务会隐式提交
属性框架定义的事体绑定和劳务的很壹般。事务的运行和解释也和劳动的职业状态10分：
· 对于展现运转的事情，事务events在start transaction后开发银行。
· 对于隐式运转的作业，事务事件在首先个语句推行的时候运转。
· 对于其他工作，当实行commit，rollback事务结束。
玄奥的不一样点：
· 品质框架中的事务事件，未有完全包括语句事件比如START TRANSACTION,COMMIT，ROLLBACK语句。
· 语句如果运营在非实物引擎，那么连接的作业状态不会影响。
事情记录点
二个概念的事体属性：
· 访问情势(read only,read write)
· 隔开等第
· 隐式只怕展现
为了削减工作记录点并且保证收罗职业数据是做到的，有含义的结果，全数工作都有访问形式，隔断等第，自动提交格局。
事务事件表使用3列来ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT记录。
工作记录点消费能够有很两种办法减弱，比如依据用户，账号，host，thread运营可能禁止使用事务减了点。
线程和嵌套事件
作业事件的上司事件是初始化事务的风云。对于彰显事务运行，包括START_TRANSACTION和commit and china,假设是隐式事务，第2个语句运转职业。
展现的截止工作，COMMIT,ROLLBACK，只怕DDL语句，隐式的交付业务。
政工和存款和储蓄进度
作业和仓库储存进程事件涉及如下：
· 存款和储蓄进程
存款和储蓄进程操作独立的工作，二个储存进程可以运维贰个事务，并且3个事务可以在仓库储存进度中运营和终结。要是在贰个事情中调用，三个存款和储蓄进程能够语句强制提交业务并且运转叁个新的事情。
· 存款和储蓄函数
仓库储存函数能够限制展现可能隐式的事情提交和回滚。
· 触发器
触发器活动是语句的运动访问相关的表，所以触发器事件的顶头上司事件激活它。
· 调度事件
事件体的口舌调度事件发生叁个新连接。
事务和savepoint
Savepoint语句以独立的说话事件被记录。语句事件包罗SAVEPOINT,ROLLBACK TO SAVEPOINT和RELEASE SAVEPOINT语句。
政工和谬误 作业中的错误和警戒被记录在说话事件中，不过不在相关的事务事件。
用户自定义变量记录表
二三.⑨.三 品质框架实例表
|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |
23.9.11.2 replication_connection_status
表保存了io线程的动静，io线程连接到master服务获得binary log音信。
Replication_connection_status相关列：
· CHANNEL_NAME：来源名。
· GOURP_NAME:保留
· SOURCE_UUID：master的server_uuid
· THREAD_ID:io 线程id
· SERVICE_STATE:服务情形
· RECEIVED_TRANSACTION_SET：GTID集合反应已经被slave收到的GTID。
· LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:错误好和错误新闻。
· LAST_ERROR_TIMESTAMP:错误的轩然大波格式为YYMMDD HH:MM:SS。
· LAST_HEARTBEAT_TIMESTAMP:最近贰次心跳事件的事件。
· COUNT_RECEIVED_HEARTBEATS:收到的心跳次数。
admin@localhost : performance_schema 02:50:18> select * from replication_applier_status_by_worker;
23.9.5.1 events_stages_current表
Events_stages_current表包蕴当前stage事件，每行2个线程线程当前景观监察和控制到的stage事件。
Events_stages_current表可以truncate table。
表events_stages_current是events_stages_history和events_stages_history_long的基础。
Events_Stages_current列：
· THREAD_ID,EVENT_ID
线程相关的事件和线程当前事件号。那2个字段形成主键来标示壹行。
· END_EVENT_ID
当事件运行，这几个列为null，借使时间结束分配一个事件号。
· EVENT_NAME
浮动事件的笔录点名。
· SOURCE
源代码文件名包蕴产闹事件的记录点代码地点。能够帮忙用来检查源代码。
· TIMER_START,TIMER_END,TIMER_WAIT
事件的timing新闻。时间单位为飞秒。TIME中华V_START,TIMER_END表示事件的发轫和告竣。TIME汉兰达_WAIT是事件的持续时间。要是事件未有马到功成TIME奥德赛_END,TIMER_WAIT为null。假设记录点的timed=no那么那3个列都以null。
· WORK_COMPLETED,WORK_ESTIMATED
那么些列提供了stage过程音讯，对于记录点已经用来生成那一个音信。WOCR-VK_COMPLETED表示有些许办事单元已经被成功，WO奥迪Q7K_ESTIMATED代表有微微办事单元估算的stage。
· NESTING_EVENT_ID
EVENT_ID nested生成的风浪。嵌套的event的stage事件平常是语句事件。
· NESTING_EVENT_TYPE
嵌套事件类型，TRANSACTION,STATEMENT,STAGE,WAIT在那之中三个。
表中各字段含义以及与change master to语句的精选对应关系如下：
二三.1二 质量框架种类变量
具体看：
# global_variables表
二叁.9.玖 质量框架连接属性表
具体看：
COUNT_INIT_CONNECT_ERRORS: 0
2三.14 质量框架内部存款和储蓄器分配模型
在mysql 伍.7.六事先，质量框架使用以下内存分配模型：
· 全体的内设有运行时分配。
· 服务操作的时候不分配内部存款和储蓄器。
· 服务操作的时候不自由内部存款和储蓄器。
· 在劳务关闭的时候释放内部存款和储蓄器。
选拔这几个模型，品质框架会分配大量的内部存储器，除非展现的铺排。Mysql 伍.七.六之后的分配模型：
· 能够在服务运维的时候分配。
· 能够在服务操作的时候额外分配。
· 在服务操作的时候不自由。
· 在服务关闭的时候释放内部存款和储蓄器。
如此那般能够依据负荷来调动内部存款和储蓄器使用，不是现实性配置。
有一部分性质框架配置参数是半自动分配，也能够手动分配：
performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size
对此活动配置的参数，配置中央如下：
· 若是为-一，暗中认可，参数是机关配置的。
§ 开始对应的里边buffer为空，没有内部存款和储蓄器。
§ 当质量框架初叶搜集数据，没存被分配到想要的buffer。buffer大小未有上限，随着负荷上升上升。
· 纵然设置为0：
§ 起初内部buffer为空，也不会分配内部存款和储蓄器。
· 若是设置的N>0:
§ 对象的里边buffer为空，并且不分配内部存款和储蓄器。
§ 当数据起先采撷，内存初阶分配，直到设置的深浅。
§ 1旦buffer大小到达N，内部存款和储蓄器就不再分配。品质框架收罗的数量会丢掉，对应的状态变量的lost instance会扩大。
为了查看品质框架使用了不怎么内部存款和储蓄器，检查记录点。质量框架搜聚了种种buffer的内部存款和储蓄器使用新闻。那样能够跟踪每一种buffer的内部存款和储蓄器使用状态。记录点，memory/performance _schema/。因为这个buffer是全局的，所以只在memory_summary_global_by_event_ name上展现。查询如下：
SELECT * FROM memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';
23.9.2.3 setup_instruments表
Setup_consumers表列了颇具记录点对象：
mysql> SELECT * FROM setup_instruments;
种种记录点被扩张到源代码中，都会在这么些表上有1行，固然记录点代码未有被钦点。当三个记录点运营了依然推行了，记录点实例就会被创造会来得在*_instrances表。
修改setup_instruments行会立即影响监察和控制。对于一些记录点，修改只会在下次开发银行才会生效。在指按期修改并不会收效。
PS：
23.9.11.8 replication_group_member_status
表保存了replication group成员的状态，replication_group_member_status:
· CHANNEL_NAME:复制来源名。
· VIEW_ID：该group的当前的view标示符。
· MEMBER_ID:member标示，和uuid一样。
· COUNT_TRANSACTIONS_IN_QUEUE：pending事务的个数。
· COUNT_TRANSACTIONS_CHECKED:已经被成员证实的作业个数。
· COUNT_CONFLICTS_DETECTED:冲突发现个数。
· COUNT_TRANSACTIONS_VALIDATING:事务可以施行检查，可是尚未被回收的个数。
· TRANSACTIONS_COMMITTED_ALL_MEMBE奔驰G级S:固化的group事务集合。
· LAST_CONFLICT_FREE_TRANSACTION:最后一个不曾争辩的被验证的作业。
LAST _HEARTBEAT_TIMESTAMP: 2018-06-12 00:55:22
2三.二 品质框架配置
不知不觉中，performance_schema类别快要接近尾声了，后天将指点大家一起踏上聚讼纷繁第陆篇的征程(全系共伍个篇章)，在那一期里，大家将为大家无微不至授课performance_schema中的复制状态与变量总括表。上面，请跟随大家一起起来performance_schema系统的就学之旅吧～
贰三.5 质量框架和处境监控
能够运用show status like ‘%perf%’查看质量框架的情状。
本性框架状态变量提供了关于记录点因为内部存款和储蓄器的原故尚未被创制或许加载的音讯。依据气象命名有几类：
· Performance_Schema_xxx_class_lost，表示有些许xxx类型的记录点不可能被加载。
· Performance_schema_xxx_instance_lost,表示有微微xxx类型的记录点不可能被创造。
· Performance_schema_xxx_handlees_lost,表示有稍许xxx类型的记录点无法被展开。
· Performance_schema_locker_lost，表示有多少日子都是要么尚未被记录。
例如，四个复信号量是记录点，可是服务不能为记录点分配内存。那么会加多performnace_schema_mutex_classes_lost。可是实信号量还是以用来对象同步。但是品质数据就不能被搜罗，假若记录点被分配，用来初阶化记录点非信号量实体。对于单身的实信号量比如全局复信号量，只有一个实例。有些时限信号量的实例个数会生成，比如种种连接的非时域信号量。假诺服务不能够创设2个钦点记录点时域信号量实体，就会大增，performance_schema_mutex_instance_lost。
倘使有以下标准：
· 服务运转参数，--performance_schema_max_mutex_classes=200，因而有200个非确定性信号量空间。
· 150时域信号量已经被加载
· 插件plugin_a有三十多个复信号量
· 插件plugin_b有十八个功率信号量
劳务为插件，分配功率信号量记录点信赖于已经分配了有个别，比如以下语句：
INSTALL PLUGIN plugin_a
那正是说服务已经有了150 37个时限信号量。
UNINSTALL PLUGIN plugin_a;
虽说插件已经卸载，可是还是有1八十八个能量信号量。全体插件代码生成的野史数据还是有效。可是新的记录点事件不会被分配。
INSTALL PLUGIN plugin_a;
服务意识317个记录点已经被分配，因而新的记录点不会被创设，并且以前分配的里边buffer会被重复采取，复信号量照旧1九十个。
INSTALL PLUGIN plugin_b;
以此动用可用时域信号量已经唯有10个了，新的插件要十多个记录点。十二个已经被加载，十二个会被撤销或许丢失。Performance_schema_mutex_classes_lost会标志这几个丢失的记录点。
mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
--------------------------------------- -------
| Variable_name | Value |
--------------------------------------- -------
| Performance_schema_mutex_classes_lost | 10 |
--------------------------------------- -------
1 row in set (0.10 sec)
Plugin_b任然会搜集实施部分记录点。
当服务不可能创设一个实信号量记录点，那么会时有产生以下情状：
· 不会有新行被插入到setup_instruments表
· Performance_Schema_mutex_classes_lost增加1
· Performance_schema_mutex_instance_lost，不会变动。
地方描述的适用于拥有记录点，不单单是功率信号量。
当Performance_Schema_mutex_classes_lost大于0那么有2种情况：
· 为了保留1些内部存款和储蓄器，你能够运行，Performance_Schema_mutex_classes=N，N小于私下认可值。暗许值是满意加载全数插件的mysql发布。可是1些插件假使不加载大概会少一点。比如你可以不加载默写存款和储蓄引擎。
· 你加载三个第一方插件，是性质框架的记录点，不过在劳务运转的时候，不允许插件记录点内部存款和储蓄器获取。因为来自第二方，那个引擎的记录点内存并不会被记录在performance_schema_max_mutex_classes.
假诺服务不可能满意插件记录点的能源，未有显示的分红愈多的 performance_schema_max_mutex_classes，那么久会并发记录点的饥饿。
如果performance_schema_max_mutex_classes.太小，未有不当会被写入到不当日志，并且在运维时并没错误。然则performance_schema上的表会丢失事件。performance_schema_max_mutex_classes_lost状态变量只是符号壹些风浪归因于创立记录点退步被删去。
若是记录点未有丢失，那么就会打招呼品质框架，当在代码中(THD::LOCK_delete)创设了时域信号量，单个记录点就会被应用。那么就供给多多频限信号量实体。那年，各种线程都有lock_delete，比如有1000个线程，1000个lock_delete数字信号量记录点实例。
若果服务未有空间存放全数一千个非时域信号量记录点实体，1些时域信号量会被创制记录点，一些就不会被创造。假若服务效能创建800个，那么此外200个会丢掉，Performance_schema_mutex_instances_lost会增加200个。
Performance_schema_mutex_instances_lost，或者在要开头化的功率信号量记录点大于配置的Performance_schema_mutex_instances=N那么久会生出。
假诺SHOW STATUS LIKE 'perf%'未有丢失任何事物，那么新能框架数据是足以被信赖的。假若有一对都是了，那么数量是不完整的，并且品质框架不会记录全部。那样Performance_schema_xxx_lost就证明了难点范围。
多少时候饥饿时得以平衡的，比如您或然不要求文件io的数量，那么可以把全体品质框架参数，和文件io相关的都安装为0，那么久不会把内部存款和储蓄器分配到和文书有关的类，对象实例只怕句柄中。
-------------------------- ----------------
23.9.11.3 replication_applier_configure
这几个表呈现了影响工作应用的配置参数。参数保存在表能够透过change master to修改。
Replication_applier_configure表有以下列：
· CHANNEL_NAME:复制来源名。
· DIESIRED_DELAY:master到slave的延迟。
admin@localhost : performance_schema 04:08 :36> select * from status_by_account where USER is notnull limit 5;
23.9.11.6 replication_applier_statys_by_worker
对于多线程的slave，slave使用多个办事线程和2个和谐线程，协调线程用来管监护人业线程，表呈现了协调线程的状态。假如是单线程slave，表为空。
Replication_applier_status_by_worker:
· CHANNEL_NAME:复制来源名。
· WORKER_ID:worker标志符。Stop slave之后线程id会造成null，workerid会保留。
· THREAD_ID：线程id
· SERVICE_STATE:on，表示活动照旧空闲，off表示不存在。
· 表示worker发现的最新的事体，如果gtid_mode=off列的值为ANONYMOUS。假设为on：
§ 假设无业被实行，那么正是空。
§ 当有多个政工被实践了列设置成gtid_next。
§ GTID会被保留，知道下二个事务运维成功。
§ 当下多少个GTID被其余线程获取，从gtid_next上获得。
· LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE：最终二次错误号和错误音讯。
· LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。
| 45 |master_heartbeat_period | 5000000000 |
二三.1 品质框架快速运维
对此质量框架要启用，须求求在MySQL编写翻译的时候配置好。能够经过mysqld的相助验证。假设质量框架可用输出就会带—performance_schema参数。
假设这个参数未有出现，那么代码在编译时就不扶助质量框架。
借使品质框架可用，暗许是可用的。能够由此安插文件配置：
[mysqld]
performance_schema=ON
当服务运转，发现performance_schema就会准备起初化品质框架，能够查看performance_schema变量检查开端化是还是不是中标。
mysql> SHOW VARIABLES LIKE 'performance_schema';
-------------------- -------
| Variable_name | Value |
-------------------- -------
| performance_schema | ON |
-------------------- -------
以此值表示，品质框架已经可用，假若为off表示产生错误，检查错误日志。
个性框架实现和仓库储存引擎类似。要是引擎可用可以在show engine查看是还是不是协助PE奥迪Q五FO哈弗MANCE_SCHEMA存款和储蓄引擎。
Performance_schema中的数据库能够被分开为几块，当前岁月，历史事件，总括，对象实例和安装消息。
本来，其实并不是富有的记录点和采集器都以可用。所以品质框架不会征集全部的多少。能够透过以下语句张开装有的积累点和搜聚器：
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES';
Query OK, 560 rows affected (0.04 sec)
mysql> UPDATE setup_consumers SET ENABLED = 'YES';
Query OK, 10 rows affected (0.00 sec)
时下事变表，可以因此events_waits_current查看当前劳动在做哪些。种种线程都有1行。
历史表，表结构和脚下风浪一样，event_waits_history和event_waits_history_long表包涵了各种线程近年来13个event和各样线程近日一千0个events。
二个新的事件被参与，老的风云就会去除。
总结表提供了颇具事件的集纳的新闻。这么些表经过分组一分裂措施测算事件数量。为了查看那三个记录点呗执行的次数最多可能等待事件最长，通过对表上的count_star或者sum_timer_wait列举行排序：
mysql> SELECT EVENT_NAME, COUNT_STAR
-> FROM events_waits_summary_global_by_event_name
-> ORDER BY COUNT_STAR DESC LIMIT 10;
--------------------------------------------------- ------------
| EVENT_NAME | COUNT_STAR |
--------------------------------------------------- ------------
| wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |
| wait/io/file/sql/FRM | 452 |
| wait/synch/mutex/sql/LOCK_plugin | 337 |
| wait/synch/mutex/mysys/THR_LOCK_open | 187 |
| wait/synch/mutex/mysys/LOCK_alarm | 147 |
| wait/synch/mutex/sql/THD::LOCK_thd_data | 115 |
| wait/io/file/myisam/kfile | 102 |
| wait/synch/mutex/sql/LOCK_global_system_variables | 89 |
| wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |
| wait/synch/mutex/sql/LOCK_open | 88 |
--------------------------------------------------- ------------
mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT
-> FROM events_waits_summary_global_by_event_name
-> ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
---------------------------------------- ----------------
| EVENT_NAME | SUM_TIMER_WAIT |
---------------------------------------- ----------------
| wait/io/file/sql/MYSQL_LOG | 1599816582 |
| wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |
| wait/io/file/sql/binlog_index | 1385291934 |
| wait/io/file/sql/FRM | 1292823243 |
| wait/io/file/myisam/kfile | 411193611 |
| wait/io/file/myisam/dfile | 322401645 |
| wait/synch/mutex/mysys/LOCK_alarm | 145126935 |
| wait/io/file/sql/casetest | 104324715 |
| wait/synch/mutex/sql/LOCK_plugin | 86027823 |
| wait/io/file/sql/pid | 72591750 |
---------------------------------------- ----------------
如，上面结果TH途锐_LOCK时限信号量是看好，2个语句分别代表实施的光热和等待事件长度。
实例表，记录了指标类型被记录了。当服务使用了1个笔录对象，那么会时有产生2个轩然大波。那么些表提供了轩然大波名，解释性的注释只怕状态。比如file_instances表，记录了文本io操作和她们相应的文件。
mysql> SELECT * FROM file_instancesG
*************************** 1. row ***************************
FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...
Setup表用来配置和监督检查特点的，比如setup_timers表：
mysql> SELECT * FROM setup_timers;
------------- -------------
| NAME | TIMER_NAME |
------------- -------------
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
------------- -------------
Setup_instruments列了什么样能够被记录的风云。然后通过修改那一个表开调整是或不是运维那些记录。
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
-> WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';
属性框架使用，搜聚来的轩然大波来更新到performance_schema数据库，数据库作为事件消息的主顾。Setup_consumers表列出了可用的顾客。
调节是还是不是品质框架爱戴三个消费者作为事件音信的靶子。能够安装为enabled值。
- THREAD_ID：会话等第系统变量对应的线程ID
- VARIABLE_NAME：会话品级系统变量名
- VARIABLE_VALUE：会话级别系统变量值
23 MySQL Performance Schema
23 MySQL Performance Schema.. 1
贰叁.壹 品质框架急速运维... 叁
贰3.2 质量框架配置... 五
二三.2.一 品质框架编写翻译时配置... 5
二三.二.2 质量框架运维配置... 陆
二三.二.三 运维时品质框架配置... 8
2三.贰.3.壹 质量架构事件按期... 8
贰三.二.三.2 品质框架事件过滤... 玖
二三.2.3.叁 事件预过滤... 十
二三.2.三.四命名记录点也许消费者的过滤... 1二
2三.2.三.5 识别哪些已经被记录... 1贰
2叁.3 品质框架查询... 13
二3.4 质量框架记录点命名约定... 一3
2三.伍 质量框架和状态监察和控制... 一五
二3.陆 品质框架和分子原子性事件... 1⑦
二三.7 质量框架statement digests17
2三.八 质量框架常用表性子... 1玖
二三.九 质量框架表描述... 1九
贰三.九.1 品质框架表索引... 1九
二3.玖.贰 质量框架setup表... 1玖
23.9.2.1 setup_actors表... 19
23.9.2.2 setup_consumers表... 20
23.9.2.3 setup_instruments表... 20
23.9.2.4 setup_objects表... 21
23.9.2.5 setup_timers表... 22
2三.9.叁 品质框架实例表... 22
23.9.3.1 cond_instances表... 22
23.9.3.2 file_instances表... 22
23.9.3.3 mutex_instances表... 22
23.9.3.4 Rwlock_instances表... 23
23.9.3.5 socket_instance表... 23
贰叁.玖.四 品质框架事件等待表... 贰5
23.9.4.1 events_waits_current表... 26
23.9.4.2 Events_waits_history表... 28
23.9.4.3 events_waits_history_long 表... 28
二三.九.伍 品质框架Stage事件表... 2八
23.9.5.1 events_stages_current表... 30
23.9.5.2 events_stage_history表... 30
23.9.5.3 events_stage_history_long表... 31
二3.九.陆 品质框架语句事件表... 3一
二三.九.七 质量框架事务表... 3贰
二叁.九.八 品质框架连接表... 35
二三.九.玖 品质框架连接属性表... 3伍
2三.玖.10 品质框架用户变量表... 3伍
二三.九.1一 品质框架复制表... 36
23.9.11.1 replication_connection_configure表... 38
23.9.11.2 replication_connection_status38
23.9.11.3 replication_applier_configure. 39
23.9.11.4 replication_applier_status39
23.9.11.5 replication_applier_status_by_coordinator39
23.9.11.6 replication_applier_statys_by_worker40
23.9.11.7 replication_group_members40
23.9.11.8 replication_group_member_status40
二三.玖.1二 性能框架锁相关表... 4壹
23.9.12.1 metadata_locks41
23.9.12.2 table_handles42
贰三.玖.一三 品质框架体系变量表... 4二
二3.玖.1四 质量框架种类状态变量表... 4三
贰三.玖.一五 质量框架计算表... 四三
23.玖.1⑥ 质量框架别的表... 4四
二三.十 品质框架选项和变量... 四五
二三.11 品质框架命令选项... 四5
二三.1二 质量框架种类变量... 四伍
2叁.一叁 质量框架状态变量... 45
二三.1四 品质框架内部存款和储蓄器分配模型... 45
23.1伍 质量框架和... 四6
二3.1陆 使用品质框架检查判断... 四七
二3.17 迁移到质量框架体系和状态变量表... 4七
MySQL Performance Schema用来监督MySQL Server的周转运转在底层。品质框架有这么些特色：
· 品质框架提供了壹种格局检查其中的劳动运转。通过PEEvoqueFORubiconMANCE_SCHEMA存款和储蓄引擎和performance_schema完结。质量框架首要关切于数据品质。和INFO君越MANCE_SCHEMA不同，INFORMACE_SCHEMA重要检查元数据。
· 品质框架监察和控制服务事件，事件是劳务须求花时间的其余东西，并且1度被记录如此时间讯息能够被搜聚。平日一个事件能够是贰个函数调用，1个操作系统等待，SQL语句试行的等第比如解析大概排序，也许全部讲话可能一组语句。时间采访提供。时间搜聚提供了合伙调用文件和表IO,表锁等新闻。
· 质量框架事件的轩然大波和binlog的轩然大波，事件调度的事件区别。
· 品质框架事件被钦点到某些MySQL服务。质量框架表外人自个儿是地点服务，他们的改换不会被写入到binary log，也不会被复制。
· 当前风浪，历史事件和事件下结论是可用的，那么就可以规定记录被运维了多少次，用了不怎么日子。事件新闻方可查阅钦命线程的位移恐怕钦定对象的移位，比如文件和功率信号量。
· PERFORMANCE_SCHEMA存款和储蓄引擎使用代码中的记录点来采访信息。
· 收罗的音信被保留在performance_schema数据库中。能够用select查询。
· 品质框架配置能够动态的被退换，通过修改performance_schema数据库配置数据搜聚。
· Performance_schema上的表是视图或然一时半刻表，不会保留到磁盘中。
· MySQL帮忙具备平台的监督。
· 通过在源代码中参与记录点达成数量搜集。未有特定线程使用相关的习性框架。
---------------------------- ----------- ----------- --------------- ------------------------------------------------ ------------------- -------------------- ----------------------
23.9.2.2 setup_consumers表
Setup_consumers表列了壹壹档次的主顾：
mysql> SELECT * FROM setup_consumers;
---------------------------------- ---------
| NAME | ENABLED |
---------------------------------- ---------
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
---------------------------------- ---------
Setup_consumers设置形成从高到低的等第。产生注重，假设高端别的安装了低端别才会有机遇被检查。
|45| Bytes_sent |2901|
23.9.3.4 Rwlock_instances表
Rwlock_instances表列出了富有rwlock的实例。RAV四wlock是共同机制用来强制在自然规则下，在给定的轩然大波之中能访问片段财富。那一个财富被rwlock珍视。访问要不是共享艺术要不是排他情势，如若允许非1致性访问，还足以共享排他方式访问。Sxlock唯有在，mysql 伍.7随后技能被使用，用来优化并发性。
据悉访问的须求，所的央求要不是，共享，排他，共享排他可能不授权，等待别的线程实现。
表列如下：
· NAME：记录点名相关的lock
· OBJECT_INSTANCE_BEGIN:被记录的锁在内部存款和储蓄器中的地址。
· WRITE_LOCKED_BY_THREAD_ID:当一个线程有2个rwlock，排他形式，W奥德赛ITE_LOCKED_BY_THREAD_ID,正是锁定线程的thread_id。
· READ_LOCKED_BY_COUNT:当线程当前有贰个rwlock共享情势，那么read_locked_by_count扩充1。只是个计数，所以找不到不行线程具备了读锁，不过足以用来查看是不是有读锁，有些许读是运动的。
经超过实际行查询一下表，何以知道瓶颈和死锁：
· Events_waits_current,查看等待哪些rwlock
· Rwlock_instrances,查看别的线程是不是富有那一个锁。
只可以知道相当线程有了write lock但是不明了哪些线程有read lock。
| CHANNEL_NAME |DESIRED_DELAY |
贰三.15 质量框架和
具体看：
# status_by_user表
二三.九.八 质量框架连接表
脾性框架提供了连接的总结消息。当客户端连接，在3个特定的用户名和host下。质量框架为各个账号跟踪连接。
· Accounts:每一种客户端账号的总是总结音信。
· Hosts：每种客户端hostname 的一连计算音讯。
· Users：每一种客户端用户名的连年计算新闻。
账号那里的意趣是用户增加host。连接表有CUPRADORENT_CONNECTIONS和TOTAL_CONNECTIONS列追踪全体的连日。Accounts表有USE君越和HOST列追踪用户和host。Users和hosts表有USE奥迪Q5和HOST列，追踪用户依然host。
设若客户端名user壹，user2从hosta,hostb连接过来。质量框架追踪连接入选：
· Accounts会有4条记录，user1/hosta,user1/hostb,user2/hosta,user2/host2.
· Users表有2条记录，user1，user2
· Host表有2条记录，hosta,hostb
当客户端连接，连接表中一旦不存在这么的用户依旧host，那么就大增壹行不然就修改CU宝马7系RENT_CONNECTIONS和TOTAL_CONNECTIONS列。
当客户端断开连接，品质框架收缩current_connecitons列。
品质框架也计数内部线程和用户会电话线程验证错误。对应的user和host为null。
各类连接表都能够truncate：
· 行尽管是CU奥德赛RENT_CONNECTIONS=0的就删除
· 如果>0,TOTAL_CONNECTIONS设置为CURRENT_CONNECTIONS。
· 连接合计表信赖于连接表的值会被设为0.
02
23.9.5.3 events_stage_history_long表
Events_stages_history_long为种种线程保留了N个记录，具体能够通过安顿参数修改：
performance_schema_events_stages_history_long_size
HOST_VALIDATED: YES
2三.玖.四 质量框架事件等待表
事件等待表有三个：
· Events_waits_current:当前事变等待表
· Events_waits_history:历史等待历史表，方今的等待事件表
· Events_waits_history_long:多数事变等待历史的表。
伺机历史配置
为了搜罗等待事件，运维相应的记录点和买主。
mysql> SELECT * FROM setup_instruments
-> WHERE NAME LIKE 'wait/io/file/innodb%';
-------------------------------------- --------- -------
| NAME | ENABLED | TIMED |
-------------------------------------- --------- -------
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
-------------------------------------- --------- -------
mysql> SELECT * FROM setup_instruments WHERE
-> NAME LIKE 'wait/io/socket/%';
---------------------------------------- --------- -------
| NAME | ENABLED | TIMED |
---------------------------------------- --------- -------
| wait/io/socket/sql/server_tcpip_socket | NO | NO |
| wait/io/socket/sql/server_unix_socket | NO | NO |
| wait/io/socket/sql/client_connection | NO | NO |
---------------------------------------- --------- -------
修改enabled和timing列：
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
-> WHERE NAME LIKE 'wait/io/socket/sql/%';
Setup_consumers包括消费者对应到刚刚的风浪表。这一个消费者用来过滤等待事件的征集，私下认可被剥夺：
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%waits%';
--------------------------- ---------
| NAME | ENABLED |
--------------------------- ---------
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
--------------------------- ---------
启航全体的等候事件：
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
-> WHERE NAME LIKE '%waits%';
Setup_timers表包括了一条龙name为wait，表示等待事件的定期的单位，暗中认可是cycle：
mysql> SELECT * FROM setup_timers WHERE NAME = 'wait';
------ ------------
| NAME | TIMER_NAME |
------ ------------
| wait | CYCLE |
------ ------------
修改定期单位时间：
mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'
-> WHERE NAME = 'wait';
global_status和session_status表字段含义如下：
二三.玖.10 质量框架用户变量表
具体看:
COUNT_NAMEINFO_TRANSIENT_ERRORS: 0
[MySQL Reference Manual] 23 Performance Schema结构，manualschema
admin@localhost : performance_schema 04:08:58> select * from status_by_user where USER is notnull limit 5;
二3.九.壹 质量框架表索引
具体看：
- global_status：实施truncate会重新初始化线程、帐户、主机、用户相关的全局状态变量值，但不会重新恢复设置一些未曾重新设置的大局状态变量值，同时会影响到status_by_account表中的状态变量值
- session_status：不支持推行truncate语句
- status_by_thread：将有着线程的动静变量值聚合到全局状态变量表(global_status)和帐户状态变量表(status_by_account)，然后重新恢复设置线程状态变量表。假如不采访帐户相关的总计音讯，则会在status_by_user和status_by_host中单独采访主机和用户的状态变量值，是不是搜集host，user，account的状态变量值，能够动用系统变量performance_schema_accounts_size，performance_schema_hosts_size和performance_schema_users_size在server运转之前分别展开设置，设置为0，则意味着不采访，大于0则意味要搜罗（注意，那几个种类变量原本是用以调整accounts、hosts、users表中的行数，可是status_by_account，status_by_user，status_by_host中的account，user，host值是出自于accounts、hosts、users表，so…你懂的）
23.9.4.2 Events_waits_history表
Events_waits_history表每一种线程包括了不久前N条数据。表结构和events_waits_current一行，也足以被truncate table，N是服务运营自动安装的，也得以从参数设置: performance_schema_events_waits_history_size。
| 45 |slave_uuid | 4b0027eb-6223-11e7-94ad-525400950aac |
二3.二.1 质量框架编写翻译时安排
为了让品质框架启用必须在编写翻译时被布署，由法定提供的MySQL是帮忙质量框架的，假设是其余发表方公布的，那么要先检查是还是不是援救。
如借使从源代码公布的，那么在宣布的时候要先安装：
shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1
在MySQL 伍.七.3后头，也得以支撑运营品质框架，可是不含有全体的记录点，比如：
shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1
-DDISABLE_PSI_STAGE=1
-DDISABLE_PSI_STATEMENT=1
比方你安装MySQL到1个老的装置上，并且未有布置过质量框架，当确定保证performance_schema数据库包括了颇具的如今表后，可以使用mysql_upgrade运营服务。然后重启，有个迹象要越发留心：
[ERROR] Native table 'performance_schema'.'events_waits_history'
has the wrong structure
[ERROR] Native table
'performance_schema'.'events_waits_history_long'has the wrong
structure
...
透过以下查看mysql是不是援助质量框架：
shell> mysqld --verbose --help
...
--performance_schema
Enable the performance schema.
--performance_schema_events_waits_history_long_size=#
Number of rows in events_waits_history_long.
...
也能够透过两次三番到劳动之后选拔show engine查看是或不是留存PE福特ExplorerFOPAJEROMANCE_SCHEMA存款和储蓄引擎。就算在build的时候未有被安插那么show engines不会议及展览示PEEscortFO卡宴MANCE_SCHEMA存款和储蓄引擎。
----------- ------------------------- --------------------------------------
23.9.11.4 replication_applier_status
表保存了slave平时事务试行的情景。
replication_aplier_status列名：
· CHANNEL_NAME:复制来源名。
· SERVICE_STATE:呈现on表示复制门路活动还是空闲，要是为off表示应用线程未有活动。
· REMAINING_DELAY:如果slave等待DESIRED_DELAY直到master应用事件。列展现剩下的秒数。
· COUNT_TRANSACTIONS_RET奔驰G级IES:突显了sql thread应用工作错误，导致重试的次数。
admin@localhost : performance_schema 11:01:51> select * from global_status limit 5;
23.9.2.4 setup_objects表
Setup_objects表调整了什么对象的性质框架会被监察和控制。那么些目的默感觉100行能够透过修改动量来支配，performance_schema_setup_objects_size。
初步化的setup_objects如下：
mysql> SELECT * FROM setup_objects;
------------- -------------------- ------------- --------- -------
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
------------- -------------------- ------------- --------- -------
| EVENT | mysql | % | NO | NO |
| EVENT | performance_schema | % | NO | NO |
| EVENT | information_schema | % | NO | NO |
| EVENT | % | % | YES | YES |
| FUNCTION | mysql | % | NO | NO |
| FUNCTION | performance_schema | % | NO | NO |
| FUNCTION | information_schema | % | NO | NO |
| FUNCTION | % | % | YES | YES |
| PROCEDURE | mysql | % | NO | NO |
| PROCEDURE | performance_schema | % | NO | NO |
| PROCEDURE | information_schema | % | NO | NO |
| PROCEDURE | % | % | YES | YES |
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
| TRIGGER | mysql | % | NO | NO |
| TRIGGER | performance_schema | % | NO | NO |
| TRIGGER | information_schema | % | NO | NO |
| TRIGGER | % | % | YES | YES |
------------- -------------------- ------------- --------- -------
修改setup_objects表会立刻影响监察和控制。
对于setup_objects，object_type代表监控了什么样对象类型。倘诺未有相配的object_schema,object_name。那么就不会有指标没监理。
SSL _CA_PATH:
23.9.11.5 replication_applier_status_by_coordinator
对于二十十二线程的slave，slave使用三个干活线程和三个体协会调线程，协调线程用来管管事人业线程，表呈现了和谐线程的情况。假设是单线程slave，表为空。
Replication_applier_status_by_coordinator列：
· CHANNEL_NAME:复制来源名。
· THREAD_ID:SQL/协调线程id。
· LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE：最后2遍错误号和错误音讯。
· LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。
- show_compatibility_5陆系统变量的值会影响这个表中的音信记录
- 对话变量表（session_variables，variables_by_thread）仅包括活跃会话的音信，已经告壹段落的对话不会记录
- variables_by_thread表仅包涵关于前台线程的对话品级系统变量消息。且只记录拥有会话级其余系统变量，其余，假如在该表中有不可见被记录的对话等第系统变量，那么将净增状态变量Performance_schema_thread_instances_lost的值
23.二.叁.三.贰 对象预过滤
Setup_objects表调整了质量框架部分表和仓库储存进程。修改Setup_objects会即时相应。
mysql> SELECT * FROM setup_objects;
------------- -------------------- ------------- --------- -------
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
------------- -------------------- ------------- --------- -------
OBJECT_TYPE:表示对象类型，比如表只怕事件，存款和储蓄进度等。
OBJECT_SCHEMA和OBJECT_NAME包罗了schema大概指标名的字符串，也能够是通配符
ENABLED列表示对象是还是不是被监察和控制，TIMED列表示是或不是收罗timing音讯。
默许会收罗除了mysql,information_schema，performance_schema外全数的的数据库对象。
LAST _ERROR_TIMESTAMP: 0000-00-00 00:00:00
23.9.3.2 file_instances表
当钦赐文件io记录点的时候，File_instances表列出了具备品质框架能见到的拥有文件。倘诺文件在disk不过并未有被展开不会冒出在file_instrances中。当文件在次磁盘中被删除，那么file_instances中也会删除。
PS1：一般来讲系统状态变量被活动到了那一个复制状态表中举行记录(MySQL 5.7.伍版以前运用以下状态变量查看）：
--------------------------- -------------------------------------- ------------- ------------- --------------
|45| auto_increment_offset |2|
# session_variables表（查询结果与global_variables 表类似）
表中各字段含义及与show slave status输出字段对应关系如下：
--------------------------- -------------------------------------- ------------- ------------- --------------
| THREAD_ID |VARIABLE_NAME | VARIABLE_VALUE |
- VARIABLE_NAME：系统变量名
- VARIABLE_VALUE：系统变量值。对于global_variables，此列包涵全局值。对于session_variables，此列包罗当前对话生效的变量值
4 rows inset (0.00 sec)
host_cache表保存连接到server的主机相关音讯缓存，当中富含客户机主机名和IP地址新闻，能够用来防止DNS查找。该表可以利用SELECT语句实行询问，但需求在server运转在此之前开启performance_schema参数，不然表记录为空。
NETWORK_INTERFACE:
admin@localhost : performance _schema 02:51:00> select * from replication_connection_configurationG;
|admin | Bytes_sent |306781|
PS：
对于replication_applier_status_by_worker表，不允许试行TRUNCATE TABLE语句。
----------- ------------------------- ----------------
root@ localhost: performance_schema 10: 35: 47> select * from host_cacheG;
该表中记录从库用于连接到主库的计划参数，该表中贮存的布局新闻在实施change master语句时会被涂改
通过上述内容，大家从总体上可见大意驾驭了performance_schema中的复制音讯表记录了什么样消息，上面依次详细介绍那么些复制消息表。
5 rows inset (0.00 sec)
01
----------- ------------------------- ----------------
|| 43 |ON | 0 || 0000-00-00 00:00:00 |
5 rows inset (0.00 sec)
对于replication_applier_configuration表，不允许实践TRUNCATE TABLE语句。
......
-------------- ----------- ----------- --------------- ----------------------- ------------------- -------------------- ----------------------
|| 1 |44| ON || 0 || 0000-00-00 00:00:00 |
本文由威尼斯人科技发布,转载请注明来源