MySQLのsysスキーマまとめ

MySQL 5.7で標準バンドルされるsysスキーマ。その実態はperformance_schemaやinformation_schemaから「それっぽい」情報を集めているview。

5.7の機能っぽく語られるけど、前身は ps_helper でMySQL 5.5から使える（けど、5.5のperformance_schemaは情報が少なすぎて役に立つ気配がしない。オーバーヘッドもでかいし）

* MySQL 5.7ではperformance_schemaもだいぶオーバーヘッド落ち着いてきたみたいだし、デフォルトのまま取り敢えず有効にしておいた方がいい。ウチはMySQL 5.6から有効にしてる。
* CPUバウンドの場合確かにオーバーヘッドが見えるけど、I/Oネックになる場合は全然気にならない程度のオーバーヘッドだから、自信がある時だけOFFにする方がいいと思う。
* performance_schema.setup_actorsをTRUNCATEしておけば、新規接続コネクションはトラッキングOFFになるのでそれを活用するのもアリ。
* 5.6で使うには↓のやり方。

$ git clone https://github.com/MarkLeith/mysql-sys.git
$ cd mysql-sys
$ mysql -uroot -p < ./sys_56.sql

## sysスキーマでオススメのView

### sys.metrics
* 一通り監視したくなりそうなやつをSELECTだけでアクセスできるようになってるView
* こんなスクリプト で黙ってfluent_loggerで食わせるだけでKibanaのグラフが出来る。素敵。

### sys.schema_index_statistics
* どのインデックスがどの程度呼ばれていて、どの程度のレスポンスタイムなのかを見られる

### sys.schema_unused_indexes
* schema_index_statisticsの応用で、一度も呼ばれてないインデックスをリストしてくれる

### sys.statement_analysis
* リアルタイムpt-query-digestっぽい感じ。
* performance_schema..events_statements_summary_by_diges t.digest_textとJOINしないとクエリーの完全なステートメントが見えない（勝手に切り詰められている）
* 前に書いた 日々の覚書: MySQLのperformance_schemaでどれくらいの情報が見られるのか のevents_statements_summary_by_digest のView

### sys.statements_with_errors_or_warnings
* これ便利。 ワーニングを握りつぶしている悪い子はいねが？
* gtid-enforce-consistency= WARNと組み合わせてGTID有効化前の準備ができる


## sysスキーマでオススメのプロシージャ

### sys.create_synonym_db('base_database', 'synonym_database')
* やってることはCREATE DATABASE synonym_databaseして、SHOW TABLES FROM base_databaseしてテーブル名を引っこ抜いて、CREATE VIEW synonym_databaseで同じ名前のビューを作ってくれるだけ。
  * CALL sys.create_synonym_db('performance_schema', 'ps')ってしておくと、performance_schemaのタイプ数が減ってすごく捗る。今までどうして考え付かなかったのかってくらい。
  * CALL sys.create_synonym_db('informaiton_schema', 'i_s')も捗る。
* 感動したので書いてみた。sysでなきゃできないなんてことはない。

### sys.ps_setup_disable_background_threads
* バックグラウンドスレッドの統計情報を一発でOFFにする。UPDATE performance_schema.threads SET instrumented= 'No' WHERE type= 'BACKGROUND'とほぼ一緒だと思う。
* init-commandが空いてるならこれをCALLしてもいいかも

### sys.ps_setup_enable_thread
* 特定のスレッドのp_sを有効化できる。
* p_s.setup_actorsを空っぽにしておくと、その後接続してきたコネクションのトラッキングがOFFになるので、空っぽにしておいて、使いたくなった時だけ（5.5のSET profiling= 1みたいなノリで）有効にできる。
  * profilingと違って、自分以外のスレッドも有効化できる。
* 引数はSHOW PROCESSLISTのID
  * 自分自身のスレッドを指定する場合、CALL ps_setup_enable_thread(@@pseudo_thread_id); が便利。

### sys.ps_setup_save, ps_setup_reload_saved, ps_setup_reset_to_default
* 現在のperformance_schema.setup_*の中身をperformance_schema.tmp_setup_*テーブルに保管/リストアしてくれる。
* *テンポラリーテーブルに保存するので、コネクションを切ると折角保管したtmp_setup_*は失われる*
* ps_setup_saveは引数が必要。タイムアウトまでの秒数。1でいい。
* ps_setup_reload_savedは引数なし。
* ps_setup_reset_to_defaultは0または1の引数。1を指定すると、実行したクエリーを表示してくれる。
* MySQL 5.7.8のps_setup_reset_to_defaultにはバグがあって上手く動かない。5.7.9なら動く。
  * MySQL Bugs: #77927: sys.ps_setup_reset_to_default fails due to ENABLE/HISTORY column in setup_actors

### sys.ps_truncate_all_tables
* 現在までの統計情報(performance_schemaの*summary*と*history*)をクリアする。
* 引数は0または1、1にすると実行されたTRUNCATE文が表示される。


最近作ったMySQL 5.6はperformance_schemaを有効にしてて、結構便利に使ってます。sys。