まず、最新のSQL実行情報を表示します
1.レビュー上位SQL
原則最長実行時間に続いて、一般的に遅いSQLの最適化、優先順位最高数の最適化された実装、に従って、あなたは上位SQL統計後の外観にevents_statements_summary_by_digestテーブルを使用することができます。
テーブルのレコードevents_statements_summary_by_digest SQL文のテキストは1024バイトのデフォルトのみ傍受によって、完全ではない、1024バイトをこれらのSQL文のハッシュ計算、同じハッシュコード累積一緒の使用であり、performance_schema提供することを注意あなたは完全な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\G;
*************************** 1. row ***************************
SCHEMA_NAME: sbtest
DIGEST_TEXT: UPDATE `sbtest1` SET `pad` = ? WHERE `id` = ?
COUNT_STAR: 10
sum_time: 2.19 h
min_time: 216.90 us
avg_time: 13.15 m
max_time: 1.50 h
sum_lock_time: 2.04 h
SUM_ROWS_AFFECTED: 3
SUM_ROWS_SENT: 0
SUM_ROWS_EXAMINED: 4
*************************** 2. row ***************************
SCHEMA_NAME: sbtest
DIGEST_TEXT: SHOW WARNINGS
COUNT_STAR: 9
sum_time: 397.62 us
min_time: 16.50 us
avg_time: 44.18 us
max_time: 122.58 us
sum_lock_time: 0 ps
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 0
SUM_ROWS_EXAMINED: 0
......
*************************** 5. row ***************************
SCHEMA_NAME: sbtest
DIGEST_TEXT: SELECT * FROM `sbtest1` LIMIT ?
COUNT_STAR: 5
sum_time: 138.93 ms
min_time: 145.77 us
avg_time: 27.79 ms
max_time: 112.29 ms
sum_lock_time: 95.53 ms
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 104
SUM_ROWS_EXAMINED: 104
......
10 rows in set (0.00 sec)
2.レビューSQLを実行するための最近の失敗
（例：データベース操作のPythonのORMモジュール）があり同僚は、いくつかのデータベース操作用のコードを頼まれた構文エラーを報告しましたが、コードは、レコードSQL文のテキストをしない、と尋ねたかどうか、特定のSQL文にデータベース層内のビューどこが間違っているかの確認してください。この時間は、ほとんどの人が最初に考えたのエラーログを表示することです。残念ながら、SQL文の構文エラーのため、エラーログを記録しません。あなたは完全にperformance_schemaを理解していない場合、あなたはおそらく同僚を与える答え：MySQLのレベルはまた、構文エラーメッセージを記録しませんでした。
実際には、各ステートメントの実行状態のテーブルperformance_schemaにおける文のイベント・レコードは、より詳細な情報を記録している、など：events_statements_ テーブルとevents_statements_summary_by_digestテーブル（events_statements_文の実行テーブルはレコードのみをすべてのエラーメッセージを記録しますが、events_statements_summary_by_digestテーブル声明文のエラーが記録の実行中に発生し、エラーの特定のタイプ）が記録されていません。
次の文は、二つのテーブル、クエリ、エラーが発生した情報を使用する方法を示します
まず、我々は構文エラーのSQLをシミュレートし、セッション1を開きます。
root@localhost : performance_schema 05:18:09> select * from;
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エラー番号1064のクエリevents_statements_history_longテーブル、他の記録セッション（セッション2）を開き
use performance_schema
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 events_statements_history where MYSQL_ERRNO=1064\G;
*************************** 1. row ***************************
THREAD_ID: 119
EVENT_NAME: statement/sql/error
SOURCE: socket_connection.cc:101
exec_time: 71.72 us
lock_time: 0 ps
SQL_TEXT: select * from
CURRENT_SCHEMA: sbtest
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.01 sec)あなたはどのくらいのエラー番号がわからない場合、あなたは、エラーが発生した回数が0のステートメントを記録していないチェックMESSAGE_TEXTフィールドのメッセージは、それが内部に構文エラーであるということです見つけることができます
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,errors from events_statements_history where errors>0\G;
*************************** 1. row ***************************
THREAD_ID: 119
EVENT_NAME: statement/sql/error
SOURCE: socket_connection.cc:101
exec_time: 71.72 us
lock_time: 0 ps
SQL_TEXT: select * from
CURRENT_SCHEMA: sbtest
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
errors: 1
1 row in set (0.00 sec)
events_statements_summary_by_digest次の表のクエリ実行エラーが記録されたステートメントのSQLステートメントを発生して試してみてください。
まず、SQLの間違いの実装は、あるセッション1を開きます。
root@localhost : sbtest 05:32:34> select * ;
ERROR 1096 (HY000): No tables used
root@localhost : sbtest 05:40:57> select * from sbtest4 where id between 100 and 2000 and xx=1;
ERROR 1054 (42S22): Unknown column 'xx' in 'where clause'次に、記録エラーが発生し倍大きいevents_statements_summary_by_digestテーブルクエリが0である、セッションを行う2
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 events_statements_summary_by_digest where SUM_ERRORS!=0\G;
......
*************************** 10. row ***************************
SCHEMA_NAME: sbtest
DIGEST_TEXT: SELECT * # 这里就是第一个执行错误的语句
COUNT_STAR: 1
avg_time: 55.14 us
max_time: 55.14 us
sum_lock_time: 0 ps
SUM_ERRORS: 1
FIRST_SEEN: 2018-06-25 17:40:57
LAST_SEEN: 2018-06-25 17:40:57
*************************** 11. row ***************************
SCHEMA_NAME: sbtest
DIGEST_TEXT: SELECT * FROM `sbtest4` WHERE `id` BETWEEN ? AND ? AND `xx` = ? # 这里就是第二个执行错误的语句
COUNT_STAR: 1
avg_time: 101.68 us
max_time: 101.68 us
sum_lock_time: 0 ps
SUM_ERRORS: 1
FIRST_SEEN: 2018-06-25 17:41:03
LAST_SEEN: 2018-06-25 17:41:03
11 rows in set (0.00 sec)特定のエラーメッセージevents_statements_summary_by_digestテーブル、唯一の統計的なエラー文を記録しないでください。あなたは、クエリ、特定のエラーメッセージ（特定のエラーコード、エラーメッセージなど）を必要とするが、また、events_statements_historyまたはevents_statements_history_longテーブルをチェックする必要がある場合。
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 events_statements_history where MYSQL_ERRNO!=0\G;
......
*************************** 2. row ***************************
THREAD_ID: 119
EVENT_NAME: statement/sql/select
SOURCE: socket_connection.cc:101
exec_time: 55.14 us
lock_time: 0 ps
SQL_TEXT: select *
CURRENT_SCHEMA: sbtest
MESSAGE_TEXT: No tables used
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
MYSQL_ERRNO: 1096
*************************** 3. row ***************************
THREAD_ID: 119
EVENT_NAME: statement/sql/select
SOURCE: socket_connection.cc:101
exec_time: 101.68 us
lock_time: 0 ps
SQL_TEXT: select * from sbtest4 where id between 100 and 2000 and xx=1
CURRENT_SCHEMA: sbtest
MESSAGE_TEXT: Unknown column 'xx' in 'where clause'
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
MYSQL_ERRNO: 1054
3 rows in set (0.00 sec)
第二には、SQLの実行進捗情報を見ます
MariaDBのサポートは、スケジュール表示機能performance_schemaのパフォーマンスデータに依存して、最後の1は、進捗情報であるPROCESSLIST文のリターンを示していません
root@localhost Sun Jan 14 14:08:29 2018 14:08:29 [(none)]>show processlist;
+----+------+-----------+-----------+---------+------+----------------+-------------------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------+-----------+---------+------+----------------+-------------------------------------------------+----------+
| 4 | root | localhost | employees | Query | 6 | altering table | alter table salaries add index i_salary(salary) | 93.939 |
| 5 | root | localhost | NULL | Query | 0 | init | show processlist | 0.000 |
+----+------+-----------+-----------+---------+------+----------------+-------------------------------------------------+----------+
2 rows in set (0.00 sec)MySQLはまた、同様の機能を提供し、イベントのステージは、レコードや計算にステージイベントを通してワークロードは、あなたが情報を取得し、情報の文の実行段階に進行する可能性が推定できる持っている、我々は例を以下の通りには、表示する方法について説明します。
1.レビューSQL実装フェーズ
まず、私たちがセッションを開くには、イベントの構成相は、デフォルトでは有効になっていません有効にする必要があります（セッション1）
use performance_schema
Database changed
update setup_instruments set enabled='yes',timed='yes' where name like 'stage/%';
Query OK, 120 rows affected (0.00 sec)
Rows matched: 129 Changed: 120 Warnings: 0
update setup_consumers set enabled='yes' where name like '%stage%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3 Changed: 3 Warnings: 0第二セッションを開いた（セッション2）、最初のチェックなthread_id
select sys.ps_thread_id(connection_id());
+-----------------------------------+
| sys.ps_thread_id(connection_id()) |
+-----------------------------------+
| 119 |
+-----------------------------------+
1 row in set (0.00 sec)干渉（セッション1）を避けるために、古い情報をクリーンアップするには
-- 先关闭其他线程的事件记录功能，使用前面步骤查询到的thread_id
update performance_schema.threads set INSTRUMENTED='NO' where THREAD_ID!=119;
Query OK, 101 rows affected (0.00 sec)
Rows matched: 101 Changed: 101 Warnings: 0
-- 清空阶段事件的3张表
truncate events_stages_current;truncate events_stages_history;truncate events_stages_history_long;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.02 sec)さて、セッション2の背面には、SELECT文を実行します
select count(*) from sbtest.sbtest4 where id between 100 and 200;
+----------+
| count(*) |
+----------+
| 50 |
+----------+
1 row in set (0.00 sec)セッションでのクエリevents_stages_history_long表1
select THREAD_ID,EVENT_NAME,SOURCE,sys.format_time(TIMER_WAIT) as exec_time,WORK_COMPLETED,WORK_ESTIMATED from events_stages_history_long where THREAD_ID=119;
+-----------+--------------------------------+--------------------------+-----------+----------------+----------------+
| THREAD_ID | EVENT_NAME | SOURCE | exec_time | WORK_COMPLETED | WORK_ESTIMATED |
+-----------+--------------------------------+--------------------------+-----------+----------------+----------------+
| 119 | stage/sql/starting | socket_connection.cc:107 | 54.19 us | NULL | NULL |
| 119 | stage/sql/checking permissions | sql_authorization.cc:810 | 3.62 us | NULL | NULL |
| 119 | stage/sql/Opening tables | sql_base.cc:5650 | 10.54 us | NULL | NULL |
| 119 | stage/sql/init | sql_select.cc:121 | 16.73 us | NULL | NULL |
| 119 | stage/sql/System lock | lock.cc:323 | 4.77 us | NULL | NULL |
| 119 | stage/sql/optimizing | sql_optimizer.cc:151 | 4.78 us | NULL | NULL |
| 119 | stage/sql/statistics | sql_optimizer.cc:367 | 50.54 us | NULL | NULL |
| 119 | stage/sql/preparing | sql_optimizer.cc:475 | 7.79 us | NULL | NULL |
| 119 | stage/sql/executing | sql_executor.cc:119 | 381.00 ns | NULL | NULL |
| 119 | stage/sql/Sending data | sql_executor.cc:195 | 36.75 us | NULL | NULL |
| 119 | stage/sql/end | sql_select.cc:199 | 931.00 ns | NULL | NULL |
| 119 | stage/sql/query end | sql_parse.cc:4968 | 5.31 us | NULL | NULL |
| 119 | stage/sql/closing tables | sql_parse.cc:5020 | 2.26 us | NULL | NULL |
| 119 | stage/sql/freeing items | sql_parse.cc:5596 | 8.71 us | NULL | NULL |
| 119 | stage/sql/cleaning up | sql_parse.cc:1902 | 449.00 ns | NULL | NULL |
+-----------+--------------------------------+--------------------------+-----------+----------------+----------------+
15 rows in set (0.01 sec)上記のクエリデータを通して、あなたは明らかに、全体のプロセスを実行するには、select文、および各プロセスおよび他のオーバーヘッド情報の時間を見ることができます。
実装段階が似ていることDDL文？
前の干渉を避けるために、クリーニングにまず古い情報（セッション1）
truncate events_stages_current;truncate events_stages_history;truncate events_stages_history_long;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.02 sec)その後、実行DDL文（セッション2）
alter table sbtest1 add index i_c(c);この場合、1つのセッション情報内のイベントの問い合わせ相（DDL文が実行されていない、あなたは最後の行レコードの情報から参照することができ、WORK_COMPLETEDとWORK_ESTIMATED列の値は、イベントの位相が測定可能なイベントであることを示す、NULLではありません）。
select THREAD_ID,EVENT_NAME,SOURCE,sys.format_time(TIMER_WAIT) as exec_time,WORK_COMPLETED,WORK_ESTIMATED from events_stages_history_long;
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
| THREAD_ID | EVENT_NAME | SOURCE | exec_time | WORK_COMPLETED | WORK_ESTIMATED |
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
| 119 | stage/sql/starting | socket_connection.cc:107 | 44.17 us | NULL | NULL |
| 119 | stage/sql/checking permissions | sql_authorization.cc:810 | 1.46 us | NULL | NULL |
| 119 | stage/sql/checking permissions | sql_authorization.cc:810 | 2.29 us | NULL | NULL |
| 119 | stage/sql/init | sql_table.cc:9031 | 2.16 us | NULL | NULL |
| 119 | stage/sql/Opening tables | sql_base.cc:5650 | 107.57 us | NULL | NULL |
| 119 | stage/sql/setup | sql_table.cc:9271 | 19.19 us | NULL | NULL |
| 119 | stage/sql/creating table | sql_table.cc:5222 | 1.06 ms | NULL | NULL |
| 119 | stage/sql/After create | sql_table.cc:5355 | 76.22 us | NULL | NULL |
| 119 | stage/sql/System lock | lock.cc:323 | 4.38 us | NULL | NULL |
| 119 | stage/sql/preparing for alter table | sql_table.cc:7454 | 28.63 ms | NULL | NULL |
| 119 | stage/sql/altering table | sql_table.cc:7508 | 3.91 us | NULL | NULL |
| 119 | stage/innodb/alter table (read PK and internal sort) | ut0stage.h:241 | 27.09 s | 230040 | 470155 |
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
12 rows in set (0.01 sec)実行が完了するDDL文の後、再びステージはイベント情報を参照するには（セッション1）
select THREAD_ID,EVENT_NAME,SOURCE,sys.format_time(TIMER_WAIT) as exec_time,WORK_COMPLETED,WORK_ESTIMATED from events_stages_history_long;
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
| THREAD_ID | EVENT_NAME | SOURCE | exec_time | WORK_COMPLETED | WORK_ESTIMATED |
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
......
| 119 | stage/innodb/alter table (read PK and internal sort) | ut0stage.h:241 | 27.09 s | 230040 | 470155 |
| 119 | stage/innodb/alter table (merge sort) | ut0stage.h:501 | 1.15 m | 345060 | 512319 |
| 119 | stage/innodb/alter table (insert) | ut0stage.h:501 | 11.83 s | 460146 | 523733 |
| 119 | stage/innodb/alter table (flush) | ut0stage.h:501 | 18.35 s | 523658 | 523733 |
| 119 | stage/innodb/alter table (log apply index) | ut0stage.h:501 | 54.63 ms | 524042 | 524042 |
| 119 | stage/innodb/alter table (flush) | ut0stage.h:501 | 21.18 us | 524042 | 524042 |
| 119 | stage/sql/committing alter table to storage engine | sql_table.cc:7535 | 5.12 us | NULL | NULL |
| 119 | stage/innodb/alter table (end) | ut0stage.h:501 | 233.52 ms | 524042 | 524042 |
......
+-----------+------------------------------------------------------+--------------------------+-----------+----------------+----------------+
24 rows in set (0.01 sec)あなたは明確にALTER INDEX文の実装は全体のプロセスだけでなくオーバーヘッドと毎回のように上記のクエリによる情報のプロセスを追加見ることができます。最長の実行時間は、ステージ/のInnoDB / ALTERテーブル続くステージ/のInnoDB / ALTERテーブル（マージソート）、主内部データ発注する時間オーバーヘッド、本実施例に記載の索引を作成するために、（PK及び内部ソートを読み取ります）ソート・マージ操作。
長い歴史の表のイベントのデータステージが高速に生成され、10,000行の既定のクォータはすぐに再生することができる、あなたは完全な実装フェーズDDL文を参照するためには、より大きな値に設定ファイルにクォータを調整することができ、など：performance_schema_events_stages_history_long_size = 1000000、他の無関係なタスクスイッチを切るために念頭に置いて。
SQLの実行の進捗状況を確認してください2。
MySQLの公式バージョンでは、performance_schema全体ではなく、文の実装では非常に直感的なクエリメソッドの進行状況の下で、それ以降の章で提示のsys.sessionビューによって表示することができます
select * from sys.session where conn_id!=connection_id()\G;
*************************** 1. row ***************************
thd_id: 45
conn_id: 4
......
state: alter table (merge sort)
time: 30
current_statement: alter table sbtest1 add index i_c(c)
statement_latency: 29.42 s
progress: 46.40 -- 进度百分比
lock_latency: 2.19 ms
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
......
program_name: mysql
1 row in set (0.33 sec)
第三には、最近のトランザクションの実行情報を表示します
あなたは時間のスロークエリログの実行全体の長さによって計算書に問い合わせることができますが、いくつかの大規模なデータベース・トランザクション・ロールバックの実装プロセスが存在する場合、または実装プロセスがあなたをレンダリングするために異常にスロークエリログを終了しているものの。そして、あなたはevents_transactions_ *テーブルビュートランザクション・レコードのperformance_schemaを助けることができ、これらのテーブルは、トランザクションの詳細な記録がアクティブがある場合にロールバックされるか提出されているなどです。
ここでは、トランザクションのイベントをいくつかの取引をシミュレートし、ログテーブルを表示します。
まず、我々はデフォルトで有効になっていないトランザクションのイベントを有効に設定する必要があります（セッション1）
update setup_instruments set enabled='yes',timed='yes' where name like 'transaction';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
update setup_consumers set enabled='yes' where name like '%transaction%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3 Changed: 3 Warnings: 0クリーンアップ、他のトランザクションが妨害（セッション1）を避けます
truncate events_transactions_current;truncate events_transactions_history;truncate events_transactions_history_long;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)次に、トランザクションを実行するための新しいセッション（セッション2）を開き
begin;
Query OK, 0 rows affected (0.00 sec)
update sbtest1 set pad='yyy' where id=1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0セッション1つのクエリーアクティブなトランザクション、トランザクションがアクティブな現在実行中のトランザクション・イベントを表し、あなたはevents_transactions_currentからテーブルを照会する必要があります
select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_current\G;
*************************** 1. row ***************************
THREAD_ID: 47
EVENT_NAME: transaction
STATE: ACTIVE -- 活跃事务
TRX_ID: NULL
GTID: AUTOMATIC
SOURCE: transaction.cc:209
TIMER_WAIT: 21582764879000
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: READ COMMITTED
AUTOCOMMIT: NO
NESTING_EVENT_ID: 30
NESTING_EVENT_TYPE: STATEMENT
1 row in set (0.00 sec)セッション2、もはやアクティブなトランザクションを完了するためにロールバックされないことにロールバックするトランザクション
rollback;
Query OK, 0 rows affected (0.01 sec)セッション1、クエリのトランザクションイベント履歴テーブルevents_transactions_history_long
select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_history_long\G;
*************************** 1. row ***************************
THREAD_ID: 45
EVENT_NAME: transaction
STATE: ROLLED BACK -- 已回滚
TRX_ID: NULL
GTID: AUTOMATIC
SOURCE: transaction.cc:209
TIMER_WAIT: 39922043951000
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: READ COMMITTED
AUTOCOMMIT: NO
NESTING_EVENT_ID: 194
NESTING_EVENT_TYPE: STATEMENT
1 row in set (0.00 sec) シミュレートされた事務を定期的に提出
-- 会话2
begin;
Query OK, 0 rows affected (0.00 sec)
update sbtest1 set pad='yyy' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
commit;
Query OK, 0 rows affected (0.01 sec)
-- 会话1
select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_current\G;
*************************** 1. row ***************************
THREAD_ID: 44
EVENT_NAME: transaction
STATE: COMMITTED
TRX_ID: 421759004106352
GTID: AUTOMATIC
SOURCE: handler.cc:1421
TIMER_WAIT: 87595486000
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: READ COMMITTED
AUTOCOMMIT: YES
NESTING_EVENT_ID: 24003703
NESTING_EVENT_TYPE: STATEMENT
*************************** 2. row ***************************
THREAD_ID: 47
EVENT_NAME: transaction
STATE: COMMITTED
TRX_ID: NULL
GTID: ec123678-5e26-11e7-9d38-000c295e08a0:181879
SOURCE: transaction.cc:209
TIMER_WAIT: 7247256746000
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: READ COMMITTED
AUTOCOMMIT: NO
NESTING_EVENT_ID: 55
NESTING_EVENT_TYPE: STATEMENT
2 rows in set (0.00 sec)クエリは、上記のデータから分かるように、二行目のトランザクションイベントトランザクションイベント・レコードは、トランザクションが正常に送信されたことCOMMITTED状態手段です。
PS：あなたは、トランザクションイベント情報へevents_transactions_currentテーブルから照会することができますが、トランザクションは、コミットされない長い（ACTIVE状態の長いイベント）である場合の手段によって、提出されていないが、トランザクションが開始された時間内に何点見ることは非常に直感的ではありませんさinformation_schema.innodb_trx補助テーブルが決定されます。
select * from information_schema.innodb_trx\G;
*************************** 1. row ***************************
trx_id: 2454336
trx_state: RUNNING
trx_started: 2018-01-14 16:43:29
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 6
......
1 row in set (0.00 sec)参照
「MySQLのパフォーマンスの最適化ピラミッドの法則」
