以下のマニュアルのように、MySQL5.6でPerformance_schemaが大幅に強化されたことに伴い、
スロークエリの分析などにもパフォーマンススキーマステートメントイベントテーブルの利用が
推奨されるようになりました。
その仕組みに関して調べたので、メモとして残しておきたいと思います。
その際に利用する3テーブルの違いは以下の通りです。
・ events_statements_current
スレッド毎の最新のSTATEMENTSの情報を保持している
・ events_statements_history
スレッド毎の最新のSTATEMENTSの情報をX個まで保持している
（Xの値はperformance_schema_events_statements_history_size変数で制御）
・ events_statements_history_long
全体の最新のSTATEMENTSの情報をX個まで保持（スレッド毎ではない）している
（Xの値はperformance_schema_events_statements_history_long_size変数で制御）
これらの3テーブルには、以下のような仕組みで情報が蓄積されているようです。
- クエリが実行されると、その情報は即座にcurrentテーブルに記録される
- 次のクエリが実行されると、その前の情報はcurrentテーブルからhistoryテーブルに移動する
- X個の上限に達した場合は、historyテーブルから古いクエリ情報がDROPされる
- また、history_longテーブルの上限値に達した場合も、クエリ情報はDROPされる
つまり、historyテーブル と history_longテーブル はそれぞれ、「情報蓄積」の役割を果たし、
これらがあるために過去のクエリ情報を参照することが出来ます。
ただし、デフォルトではevents_statements_currentテーブルのみが有効になっています。
そのため、historyテーブル および history_longテーブル に関しては、システムの特性や
どのような情報を保持したいか、によって随時変更することが推奨されます。
例えば、常に複数スレッドが並行して動くようなシステムの場合は、historyテーブル の保持数を
上げると良く、バッチがメインのシステムの場合は、history_longテーブル を重要視すると良いはずです。
また、上限値（X）を定める各種変数に関しては、デフォルトでは「-1」（= auto-sized）となっており、起動時に自動的に値を設定します。
一方、MySQL5.7では「-1」（= auto-scaled）であり、動的に上限値が変動するようです。
なお、これらのパラメータ変数は動的変更が出来ないため、変更する場合はmy.cnfに明記してMySQL再起動が必要です。