查看最近的top sql 语句
使用 performance_schema中的语句激励表可以记录最近这段时间MySQL在执行的一些SQL语句，
这里以events_statements_history 作为例子：
查询结果按照语句完成时间倒序排序
##按照语句完成时间倒序排序
mysql> select THREAD_ID,EVENT_NAME,SOURCE,sys.format_time(timer_wait),sys.format_time(lock_time),SQL_TEXT,CURRENT_SCHEMA,MESSAGE_TEXT,ROWS_AFFECTED,ROWS_SENT,ROWS_EXAMINED from performance_schema.events_statements_history where CURRENT_SCHEMA!= 'performance_schema' order by timer_wait desc limit 10\G
通常优化SQL语句的原则是，原画执行次数最多的语句，然后是执行时间最长的语句。以上查询的结果并不是通常所说的top SQL的语句，可以使用events_statements_summary_by_digest表来查询经过统计之后的TOP SQL语句：
select SCHEMA_NAME,DIGEST_TEXT,COUNT_STAR, sys.format_time(sum_timer_wait) as sum_time, sys.format_time(min_timer_wait) as min_time, sys.format_time(avg_timer_wait) as avg_time,
sys.format_time(max_timer_wait) as max_time, sys.format_time(sum_lock_time) as sum_lock_time, SUM_ROWS_AFFECTED, SUM_ROWS_SENT,SUM_ROWS_EXAMINED from events_statements_summary_by_digest where SCHEMA_NAME is not null order by COUNT_STAR desc limit 10;
##events_statements_summary_by_digest该表中记录的SQL语句文本并不完整，默认情况下仅仅截取了1024字节，并且也是对这1024字节使用hash计算的，##把hashcode的结果累积在一起，periformance_schema提供的数据只能算作慢查询日志的补充，如果需要完整的SQL文本，还是需要依赖慢查询日志。
查询最近执行失败的SQL（找到某一具体的报错SQL）(找到语法错误的SQL)
假设，先执行了一条语法错误的SQL：
mysql> seletc * from xpp.q;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
现在要找出它：
select THREAD_ID,EVENT_NAME,SOURCE, sys.format_time(timer_wait) as exec_time, sys.format_time(lock_time) as lock_time, SQL_TEXT,CURRENT_SCHEMA,MESSAGE_TEXT,ROWS_AFFECTED,ROWS_SENT,ROWS_EXAMINED,MYSQL_ERRNO from performance_schema.events_statements_history where MYSQL_ERRNO=XXXXX \G
mysql> select THREAD_ID,EVENT_NAME,SOURCE, sys.format_time(timer_wait) as exec_time, sys.format_time(lock_time) as lock_time, SQL_TEXT,CURRENT_SCHEMA,MESSAGE_TEXT,ROWS_AFFECTED,ROWS_SENT,ROWS_EXAMINED,MYSQL_ERRNO from performance_schema.events_statements_history where MYSQL_ERRNO=1064\G
*************************** 1. row ***************************
THREAD_ID: 124
EVENT_NAME: statement/sql/error
SOURCE: init_net_server_extension.cc:93
exec_time: 67.06 us
lock_time: 0 ps
SQL_TEXT: seletc * from xpp.q
CURRENT_SCHEMA: NULL
MESSAGE_TEXT: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
MYSQL_ERRNO: 1064
1 rows in set (0.00 sec)
mysql> select errors,THREAD_ID,EVENT_NAME,SOURCE, sys.format_time(timer_wait) as exec_time, sys.format_time(lock_time) as lock_time, SQL_TEXT,CURRENT_SCHEMA,MESSAGE_TEXT,ROWS_AFFECTED,ROWS_SENT,ROWS_EXAMINED,MYSQL_ERRNO from performance_schema.events_statements_history where errors>0\G
*************************** 1. row ***************************
errors: 1
THREAD_ID: 124
EVENT_NAME: statement/sql/error
SOURCE: init_net_server_extension.cc:93
exec_time: 67.06 us
lock_time: 0 ps
SQL_TEXT: seletc * from xpp.q
CURRENT_SCHEMA: NULL
MESSAGE_TEXT: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
MYSQL_ERRNO: 1064
1 row in set (0.00 sec)
##在events_statements_summary_by_digest表中查询发生错误次数大于0的记录
mysql> select SCHEMA_NAME,DIGEST_TEXT,COUNT_STAR, sys.format_time(avg_timer_wait) as avg_time, sys.format_time(max_timer_wait) as max_time, sys.format_time(sum_lock_time) as sum_lock_time, SUM_ERRORS,FIRST_SEEN,LAST_SEEN from performance_schema.events_statements_summary_by_digest where sum_errors!=0\G
##注意，events_statements_summary_by_digest表中不记录任何具体的错误信息，只做错误语句统计。所以，如果需要查询具体的错误信息（错误代码，错误的提示信息以及具体的错误SQL文本等），还需要查询events_statements_history和events_statements_history_long表。
mysql>select * from sys.session where conn_id!=connection_id()
*************************** 31. row ***************************
thd_id: 126
conn_id: 88
user: sbtest@localhost
db: sbtest
command: Query
state: updating
time: 8
current_statement: UPDATE sbtest5 SET c='15734170 ... 900-05644653255' WHERE id=4976
statement_latency: 8.21 s
progress: NULL
lock_latency: 31.00 us
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
last_statement: NULL
last_statement_latency: NULL
current_memory: 52.88 KiB
last_wait: NULL
last_wait_latency: NULL
source: NULL
trx_latency: 8.21 s
trx_state: ACTIVE
trx_autocommit: NO
pid: NULL
program_name: NULL
##progress 表示 进度百分比
查看多线程复制的报错信息：
MySQL5.6开始支持基于库级别的并行复制，在MySQL5.7版本中支持事务的并行复制，在开启并行复制后一旦发生复制报错，使用show slave status语句无法查看到具体的报错详情。在多线程并行复制下，SQL线程的报错信息就是根据worker线程的报错信息汇总的信息。
mysql>show slave status\G
...
...
Last_SQL_Error:Coordinator stopped bacause there were error(s) in the wroker(s).The most recent failure being:Worker 1 failed executing transaction'XXXXXXXXXXXXXXXXXXXXXXXX:XXXXXX'at master log mysql-bin.000XX,end_log_pos XXXXX.See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others,if any.
...
...
根据提示查看：
select * from performance_schema.replication_applier_status_by_worker
performance_schema.replication_applier_status_by_worker详细记录了每一个worker线程的详细信息，我们可以从中找到发生报错的worker线程的具报错原因。
处于历史原因，performance_schema中复制信息记录表仅仅记录了GTID相关的信息，MYSQL系统字典库中slave_master_info，slave_relay_log_info，slave_worker_info表记录与binlog位置相关的信息。 如果选择将复制信息记录在磁盘上，磁盘上还存在master.info,relay_log.info等文件记录与binlog位置相关的信息
2020-09-18T09:50:05.258326Z 13 [ERROR] [MY-010584] [Repl] Slave I/O for channel ‘’: error connecting to master ‘repl@10.30.5.249:3306’ - retry-time: 60 retries: 113 message: Authentication plugin
‘caching_sha2_password’ reported error: Authentication requires secure connection. Error_code: MY-002061
