MySQLerの7つ道具 plus

MySQLerの七つ道具 PlusYouʼre not alone

2017/01/25

yoku0825⽇本MySQLユーザ会(MyNA)会 2017年1⽉

本編に⼊る前に

1/98

@yyamasaki1 「MySQL

ClusterはMySQLの姉妹製品」

2/98

https://twitter.com/yyamasaki1

Myちゃんの姉妹と⾔えば

3/98

Mariaちゃん

4/98

宿命のライバル（︖）

http://www.slideshare.net/Codemotion/my-sql-mariadbstorycodemotion

5/98

そしてこれが舞奈たん

https://github.com/yoku0825/MyNA/tree/master/unofficial̲myna̲girl

6/98

舞奈たん is 誰

⽇本MySQLユーザ会MySQL Nippon AssociationMyNA（まいな）マイナ（九官⿃の仲間︖）MyNAのロゴはマイナ

7/98

マイナくん（仮）

https://github.com/yoku0825/MyNA/tree/master/yet̲another̲logo

8/98

舞奈たん

マイナくん（仮）（仮）なのは俺がこのロゴの本名を知らないから-

まいな舞奈︖マイナくん（仮）の擬⼈化なので緑

9/98

はい今⽇のいちばんおもしろいとこ終わった

10/98

＼こんばんは／

yoku0825＠とある企業のDBAオラクれない-ポスグれない-マイエスキューエる-

⽣息域Twitter: @yoku0825-Blog: ⽇々の覚書-MyNA ML: ⽇本MySQLユーザ会-MySQL Casualʼs Slack: MySQL Casual-

11/98

https://twitter.com/yoku0825

https://yoku0825.blogspot.jp

http://mysql.gr.jp/

http://mysql-casual.org/

本が出ました

http://book.impress.co.jp/books/1116101077

12/98

が13/98

目次

第 1 章 MySQL クエリーチューニングことはじめ

第 2 章スローログの集計に便利な「pt-query-digest」

を使ってみよう

第 3 章 SQL 実⾏計画の疑問解決には「とりあえず

EXPLAIN」しよう

第 4 章「PMP for Cacti」で MySQL のステータスを可

視化する

14/98

目次

第 5 章 MySQL のリアルタイムモニタリングに

innotop

第 6 章再現性のあるスロークエリーには「SHOW

PROFILE」を試してみよう

第 7 章 performance̲schema を sys で使い倒す

第 8 章 MySQL のチューニングを戦う⽅へ

15/98

実はいっこもクエリチューニングしてない

MySQL （で）即効クエリチューニング（をしたくてしょうがない⼈はまずこのへんから⾒ると対象が絞り込みやすいしチューニングのためにインデックスを作る時はこんなのモニタリングしたらいいし、中⻑期的にチューニングの効果測定するならこんなツールがいいんじゃね︖）みたいな正直すまんかった

16/98

この本は

200台のMySQLの⾯倒を⾒ないといけない1台にかけられる時間は限られていてチューニング以外にもやることはもちろんあるそんな企業のDBAに

17/98

この本は

チューニングのために pt-online-schema-change を流してみたけどbinlog_format= MIXED がROWフォーマットにフォールバックされてレプリケーションぶっ壊れてあががががっていうのに気付くのが遅れたDBAとか

18/98

この本は

JOINする時に何故かインデックスが上⼿く使われなくてどういうことだと思ってプロファイルを取ってみたら暗黙の型変換が⾛ってスキャンジョインになっていることにたどり着いてちょっと嬉しくなるDBAとか

19/98

要は4年前の俺にオススメな

20/98

MySQLer七つ道具のはなし

21/98

MySQLer七つ道具

pt-query-digest1. EXPLAIN2. PMP for Cacti3. innotop4. SHOW PROFILE5. performance̲schema & sys6. ???7.

22/98

+ more

Perlに限らず、ワンライナーでゴニョゴニョできる⼿になじむ⾔語-

Dockerに限らず、好きなように作って壊せる環境-

あとTwitter「〜ってなんだったっけ︖」とつぶやくと30秒で答えが返ってくる悪夢のようなツール

-

23/98

MySQLer七つ道具


24/98

pt-query-digest

みんなだいすきPercona Toolkitの⼈気No.1スローログをまとめて⾒やすくしてくれる⼤⽂字⼩⽂字、⽂字列定数と数値定数をノーマライズして「ダイジェスト」ごとに集約

-

25/98

先頭のセクション

$ pt-query-digest /path/to/slowlog..# Time range: 2016-03-16 17:29:32 to 2016-11-22 11:37:24# Attribute total min max avg 95% stddev median# ============ ======= ======= ======= ======= ======= ======= =======# Exec time 45155s 500ms 117s 3s 7s 9s 640ms# Lock time 2s 29us 14ms 110us 176us 136us 93us# Rows sent 156.96M 0 5.85M 10.33k 54.03k 74.89k 0.99# Rows examine 36.18G 0 26.40M 2.38M 22.38M 5.41M 298.06k# Rows affecte 0 0 0 0 0 0 0# Bytes sent 9.86G 0 362.91M 664.55k 4.26M 4.87M 1.09k# Query size 3.29M 25 24.47k 221.80 346.17 425.46 136.99..

26/98

まああんま⾒ない…けど

この出⼒結果をパースして管理⽤MySQLに突っ込んでる前⽇⽐どれくらいスローログが増えたかを確認するのに使ってる

SHOW GLOBAL STATUS LIKE 'Slow_queries' の増分を取るよりはもうちょっとグラフ化して⾯⽩い程度に取れる

-

ここで「おや︖」と思ったら深掘り（anemo eat er）開始なので実はこれ以降あんまり⽣の pt-query-digest は⾒ない-

27/98

anemo eat erの前に、Anemometerのはなし

pt-query-digest の出⼒結果を可視化するツールpt-query-digest の結果をMySQLに⼊れる機能(--history, --review)をそのまま使ってるbox/Anemometer: Box SQL Slow Query Monitor

28/98

https://github.com/box/Anemometer

Anemometerの弱点

テーブル上UNIQUE KEY (hostname_max, checksum, ts_min,

ts_max)で、Anemometerはts_minでプロットするため、そのクエリーがts_minに集中したことになってしまう。

mysql> SELECT * FROM global_query_review_history LIMIT 1\G*************************** 1. row *************************** hostname_max: xxx db_max: xxx checksum: 1233945238822708500 sample: xxx ts_min: 2015-09-14 11:32:12 ts_max: 2015-10-28 15:51:01 ts_cnt: 31 Query_time_sum: 651.778 Query_time_min: 2.07993 Query_time_max: 197.678

29/98

Anemometerの弱点

⽇次で pt-query-digest を回している程度だと、⽇単位までしか分解できない

30/98

そこでanemo eat er

スローログをスプリットして pt-query-digest を呼びまくる1分ぶんずつ pt-query-digest に⾷わせれば、ts_min と ts_max の差は最⼤でも1分

-

AnemometerをDockerコンテナーとして起動する-既存のAnemometerがあれば単にスローログを分割して⾷わせる pt-query-digest のラッパーとして呼べる

-

31/98

with anemo eat er

最⼩1分単位でプロットできる

32/98

anemo eat er

リアルタイムでなくてもいいスロークエリーのリアルタイム通知は別の⽅法でしてる-グラフで⾒られれば数分前の情報であっても全然構わない-

リアルタイムを捨てて保存期間を考えないスローログが残っている限りの情報を、最初から、最後まで⾒られる

-

⾒るかどうかもわからないグラフのために常時リソースを割かなくていい⾒たく / ⾒せたくなったら起動、⾒終わったら停⽌

-

33/98

anemo eat er

現在のところ docker と pt-query-digest はホストにインストールしておかないとダメ

$ git clone https://github.com/yoku0825/anemoeater$ cd anemoeater$ ./anemoeater slow_log_fileDocker container starts with 172.17.0.43.URL will be http://xxxx:32780/anemometer

34/98

With anemo eat er

$ scp -c arcfour target_server:/data/../slow.log ./target_server_slow.log$ ./anemoeater target_server_slow.log Docker container starts with 172.17.0.3.URL will be http://192.168.230.241:32789/anemometerprocessing 2016-12-16 01:08:00 at target_server_slow.log...

デフォルトでは直近1か⽉分をCPUスレッド数 * 1.5 パラレルにして5分単位で分割する

35/98

何はなくともグラフ画⾯

36/98

“Show top queries as a separate series”

37/98

じゃん

38/98

Query̲time以外でも描画できる

39/98

⾒るところは⽣の pt-query-digest とそうそう違わない

クエリーごとにバラつきがあるか︖バラついているなら、カーディナリティーの悪戯か、それともキャッシュの具合か特にInnoDB圧縮を使ってる場合、バッファプールミスヒットやテーブルキャッシュミスヒットのコストは⼤きい

-

均等に遅いなら、それはクソクエリーかな-ただし pt-query-digest がそもそも、スローログに載っているヤーツしか⾒られない以上、まともな速度で応答を返しているヤーツは検出されない

-

詳細画⾯の “samples” から⽣のクエリーも⾒られる

40/98

⽣のpt-query-digestと上⼿く付き合うコツ

--since オプションはほぼ必須--since オプションでもログは舐めてしまうので、⼤きなログを⾷わすのであれば tail -50000 slow.log | pt-query-digest とパイプで⾷わせるのも⼿

-

「膨⼤で⾒にくいスローログの塊を、認識しやすいチャンクにまとめる」

--group-by=tables からの --group-by=fingerprint --filter='$events->{fingerprint} =~ /\sテーブル名\s/' とか

-

41/98

MySQLer七つ道具


42/98

EXPLAIN

もうみんな目XPLAIN とかできるんでしょう︖EXPLAIN EXTENDEDEXPLAIN format=json

の話しかしません

43/98

EXPLAIN EXTENDED

5.7からはデフォルトでEXTENDED & PARTITIONSがついてくる

EXPLAIN直後に SHOW WARNINGS でオプティマイザーが最適化した後のクエリーが⾒える

-

5.6まではEXTENDEDとPARTITIONSを同時に指定できなかったけど、5.7はまとめて出してくれる

-

想像したのと違う遅くなり⽅をしたらEXTENDED⾒た⽅が良い

特に5.6の蝉ジョインとか蝉ジョインとか蝉ジョインとか-

MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.8.3 EXPLAIN EXTENDED 出⼒フォーマット

44/98

http://dev.mysql.com/doc/refman/5.6/ja/explain-extended.html

EXPLAIN EXTENDED

*************************** 1. row *************************** id: 1 select_type: SIMPLE table: hg type: refpossible_keys: PRIMARY,hogehoge_idx05,hogehoge_idx09,hogehoge_idx10,hogehoge_idx11,hogehoge_idx12,hogehoge_idx13,hogehoge_idx14,hogehoge_idx15,hogehoge_idx16,hogehoge_idx17,hogehoge_idx19,idx_col2_col3_col1 key: hogehoge_idx05 key_len: 5 ref: const rows: 170287 filtered: 100.00 Extra: Using index condition; Using where; Using temporary; Using filesort*************************** 2. row *************************** id: 1 select_type: SIMPLE table: fg type: refpossible_keys: fugafuga_idx1,idx_fugafuga_04,idx_col1_col2_col3 key: idx_fugafuga_04 key_len: 7 ref: hg.col2,const rows: 5 filtered: 100.00 Extra: Using index2 rows in set, 1 warning (0.00 sec)

45/98

SHOW WARNINGS

*************************** 1. row *************************** Level: Note Code: 1003Message: /* select#1 */ select `fg`.`fugafuga_id` AS `fugafuga_id`,`hg`.`col3` AS `col3`,`hg`.`title` AS `hogehoge_title`,`hg`.`col2` AS `col2`,`hg`.`col4` AS `col4`,`hg`.`fugafuga_count` AS `fugafuga_count` from `fugafuga` `fg` join `hogehoge` `hg` where ((`fg`.`col1` = `hg`.`col2`) and (`hg`.`col2` = 210) and (`hg`.`col2` = 1) and (`fg`.`col5` = 1) and (`hg`.`col6` in (0,100,101))) order by `fg`.`fugafuga_id` desc limit 0,5

46/98

オプティマイザーを通した後の情報

想像したのと違う遅くなり⽅をしたら<semi-join> とか <materialized> とか⾒えて楽しい

47/98

EXPLAIN format=json

EXPLAIN: { "query_block": { "select_id": 1, "ordering_operation": { "using_temporary_table": true, "using_filesort": true, "nested_loop": [ { "table": { .. "rows": 170287, "filtered": 100, "index_condition": "(`hg`.`col2` is not null)", "attached_condition": "((`hg`.`col2` = 1) and (`hg`.`col6` in (0,100,101)))" }..}1 row in set, 1 warning (0.00 sec)

48/98

format=JSON

ICPな時にどこにICP当ててるのかが⾒えるくらいであんまり⾒ることはないけどVisual Explainのタネ正直これなら optimizer_trace ⾒た⽅が楽しい

49/98

Visual EXPLAIN

JSON⽂字列から直接これが描写できればいいのに

50/98

optimizer_trace

> SELECT * FROM information_schema.optimizer_trace\G*************************** 1. row *************************** QUERY: .. TRACE: { "steps": [ { "join_preparation": { "select#": 1, "steps": [ { "expanded_query": .. { "join_optimization": { "select#": 1, "steps": [ { "transformations_to_nested_joins": { "transformations": [ "outer_join_to_inner_join", "JOIN_condition_to_WHERE", "parenthesis_removal" ],.. { "index": "hogehoge_idx18", "usable": false, "cause": "not_applicable" },

MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 22143 INSUFFICIENT_PRIVILEGES: 0

51/98

MySQLer七つ道具


52/98

PMP（Percona Monitoring Plugins） for Cacti

別に for Zabbixでもいいと思う単にウチはもともとCactiを使っていたからというだけ既にカスタマイズしたぷらぎんもあるし

53/98

PMP for Cacti

rrdtoolだから容量効率は素晴らしいrrdtoolだから丸め誤差は厳しいCactiそのものがWEBからポチポチするインターフェースなのつらいss̲get̲mysql̲stats.php ⾃体はPHPで、頑張って⾊々パースしてるので、ホゲろうと思えばホゲれるけど、それならPerlで書きたい-

54/98

PMP for Cactiといえば

https://www.percona.com/doc/percona-monitoring-plugins/1.1/cacti/mysql-templates.html

55/98

Data Input Methodのデフォルトを⼀気にSQLで書き換えるとか

mysql> UPDATE data_input_fields JOIN data_input_data ON data_input_fields.id= data_input_data.data_input_field_id JOIN data_input ON data_input_fields.data_input_id = data_input.id -> SET data_input_data.value = 'pmp' WHERE data_input.name LIKE 'Percona %' AND data_input_fields.name = 'Username';

mysql> UPDATE data_input_fields JOIN data_input_data ON data_input_fields.id= data_input_data.data_input_field_id JOIN data_input ON data_input_fields.data_input_id = data_input.id -> SET data_input_data.value = 'pmp_pass' WHERE data_input.name LIKE 'Percona %' AND data_input_fields.name = 'Password';

mysql> UPDATE data_input_fields JOIN data_input_data ON data_input_fields.id= data_input_data.data_input_field_id JOIN data_input ON data_input_fields.data_input_id = data_input.id -> SET data_input_data.value = '3306', data_input_data.t_value = 'on' WHERE data_input.name LIKE 'Percona %' AND data_input_fields.name = 'Port';

56/98

Device追加する時にポートを⼀⻫に変えるブックマークレットだとか

javascript:void((function(elems,port){for(var p in elems){elems[p].value=port}})(document.querySelectorAll('input[type=text]'),prompt('port','3306')))

(c) irok

57/98

最近ちょっとPMM(Percona Monitoring

and Management)試したい

オレオレぷらぎんがどれくらい移植しやすいか次第

58/98

PMP for Cacti

やっぱり視認性だいじたまには⻑い期間で⾒る「プラグインを⾃分で書きやすいこと」も⼤事企業体⼒のある某社さん是非︕-

59/98

MySQLer七つ道具


60/98

innotop

みんな⼤好き、topライクに SHOW PROCESSLIST を表⽰してくれるinnotop地味に “M” (Replication Status) も便利なんとMSR対応してるんだぜ

-

“L” (InnoDB Locks) とか-“T” (InnoDB Transaction) とか-“M”(Replications) も便利だな-pt-osc してる間だと “D” (InnoDB Deadlocks) を眺めることもある-

tmuxでばっちんばっちんターミナル割って、 dstat とか流しながら⾒るのが好き

61/98

innotop

62/98

innotop

地味に機能は多いけど今のバージョンだと表⽰されない項目がたまにある旧バージョンのサポート切れば楽なんだけど…と思ったり思わなかったり

-

ALTER TABLE や percona-toolkit で重いことやる時のおともに最適

“d” で表⽰間隔の変更。0.1とかやるとたのしい-ただし万能感を期待しない-“Q” => “K” => “T” => “k” (killステートメント) のコンボで詰まってるのを殺すくらい

-

63/98

innotop

中⾝は結構スパゲティ最近メンテナンス遅めちょっと⾊々事情が-⽇々の覚書: innotopのその後 2016年6⽉-

ちょうど先週 (JSTで1/21) 息を吹き返したところ1.11.4 が出てる

epelへのリクエストは出したBug 1416245 – Package update request for innotop v1.11.4

-

64/98

https://yoku0825.blogspot.jp/2016/06/innotop-20166.html

https://github.com/innotop/innotop/releases/tag/v1.11.4

https://bugzilla.redhat.com/show_bug.cgi?id=1416245

MySQLer七つ道具


65/98

SHOW PROFILE

MySQLの組み込みプロファイラー「そのクエリーが実⾏されていた期間、どのStatus（SHOW

PROCESSLIST で “State” と表⽰されているもの）にどのくらいの時間かかったか使うのが超簡単

66/98

SHOW PROFILE

mysql> SET @@profiling= 1;Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> ..;

mysql> SHOW PROFILE;+----------------------+----------+| Status | Duration |+----------------------+----------+| starting | 0.000206 || checking permissions | 0.000024 || Opening tables | 0.000039 || init | 0.000089 || System lock | 0.000027 || optimizing | 0.000037 || statistics | 0.000245 || preparing | 0.000058 || Creating tmp table | 0.000119 || Sorting result | 0.000023 || executing | 0.000019 || Sending data | 2.619037 || Creating sort index | 0.000821 || end | 0.000014 || removing tmp table | 0.000017 || end | 0.000013 || query end | 0.000015 || closing tables | 0.000022 || freeing items | 0.000028 || logging slow query | 0.000109 || cleaning up | 0.000013 |+----------------------+----------+21 rows in set (0.00 sec)

67/98

SHOW PROFILE

組み込みだから使うのは超簡単プロファイルを「どう解析するか」はまた別の問題ざっと⾒てわかりやすいところに時間がかかってたらつぶせる…くらいのノリ再現性がないとつらい再現性無いなら無いで、テーブルキャッシュやバッファプールのミスヒットに視線を移すことはできるなあ

-

68/98

MySQL 5.6でdeprecated

代替として performance_schema.events_stages_* と events_statements_* が案内されている…けど@@profiling はセッション単位に対して、p̲sはセッション単位の調整がちょっと難しい⼀応、MySQL 8.0.0現在でもまだ使えるPlease “Affects me”!!

MySQL Bugs: #81928: Feature request for sys.profiling-

69/98

https://bugs.mysql.com/bug.php?id=81928

MySQLer七つ道具


70/98

performance̲schema(p̲s)

パフォーマンスモニタリング専⽤のストレージエンジンMySQL 5.6から真っ当に使えるようになってる吊るしのデフォルトではONになってる-計測する項目も「だいたい必要になりそうなところ」だけがONになってるので、必要になるまではそのまま使えばOK

-

メモリーを⾷うのは相変わらずデフォルトがautosizeなので、気になる場合は固定値を決め打つ-しかも5.7のデフォルトが auto re size になりやがった。。-

71/98

p̲s⾃体のモニタリング

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS;+--------------------+-------------------------------------------------------------+----------+| Type | Name | Status |+--------------------+-------------------------------------------------------------+----------+| performance_schema | events_waits_current.size | 176 || performance_schema | events_waits_current.count | 1536 || performance_schema | events_waits_history.size | 176 || performance_schema | events_waits_history.count | 2560 || performance_schema | events_waits_history.memory | 450560 |..| performance_schema | performance_schema.memory | 94739320 |+--------------------+-------------------------------------------------------------+----------+229 rows in set (0.00 sec)

72/98

最近お気に⼊りのp̲sクエリー

SELECT thread_id, event_name, sql_text, @progress:= (work_completed / work_estimated) * 100 AS progress, @elapsed:= (timer_current - timer_start) / power(10, 12) AS elapsed, @elapsed * (100 / @progress) - @elapsed AS estimated FROM (SELECT stage.thread_id, stage.event_name, work_completed, work_estimated, (SELECT timer_start FROM events_statements_current JOIN threads USING(thread_id) WHERE processlist_id = @@pseudo_thread_id) AS timer_current, statement.timer_start, sql_text FROM events_stages_current AS stage JOIN events_statements_current AS statement USING(thread_id)) AS dummy;

⽇々の覚書: MySQL 5.7.6のPerformance SchemaでInnoDBのALTER TABLE進捗どうですか

73/98

https://yoku0825.blogspot.jp/2015/03/mysql-576performance-schemainnodbalter.html

ALTER TABLE が⾒える…⾒えるぞ…

mysql> SELECT ..;+-----------+------------------------------------------------------+-------------------------------------+-------------+-------------+--------------------+| thread_id | event_name | sql_text | progress | elapsed | estimated |+-----------+------------------------------------------------------+-------------------------------------+-------------+-------------+--------------------+| 28 | stage/innodb/alter table (read PK and internal sort) | ALTER TABLE t1 ADD UNIQUE KEY (val) | 7.330386000 | 1.877416142 | 23.734006530694177 |+-----------+------------------------------------------------------+-------------------------------------+-------------+-------------+--------------------+1 row in set (0.15 sec)

mysql> SELECT ..;+-----------+------------------------------------------------------+-------------------------------------+--------------+--------------+------------------+| thread_id | event_name | sql_text | progress | elapsed | estimated |+-----------+------------------------------------------------------+-------------------------------------+--------------+--------------+------------------+| 28 | stage/innodb/alter table (read PK and internal sort) | ALTER TABLE t1 ADD UNIQUE KEY (val) | 46.969643300 | 33.385053874 | 37.6928839778295 |+-----------+------------------------------------------------------+-------------------------------------+--------------+--------------+------------------+1 row in set (0.01 sec)

mysql> SELECT ..;+-----------+---------------------------------------+-------------------------------------+--------------+--------------+--------------------+| thread_id | event_name | sql_text | progress | elapsed | estimated |+-----------+---------------------------------------+-------------------------------------+--------------+--------------+--------------------+| 28 | stage/innodb/alter table (merge sort) | ALTER TABLE t1 ADD UNIQUE KEY (val) | 50.831565800 | 40.169081343 | 38.854810033960106 |+-----------+---------------------------------------+-------------------------------------+--------------+--------------+--------------------+1 row in set (0.00 sec)

mysql> SELECT ..;+-----------+-----------------------------------+-------------------------------------+--------------+--------------+--------------------+| thread_id | event_name | sql_text | progress | elapsed | estimated |+-----------+-----------------------------------+-------------------------------------+--------------+--------------+--------------------+| 28 | stage/innodb/alter table (insert) | ALTER TABLE t1 ADD UNIQUE KEY (val) | 83.429283200 | 61.092267798 | 12.134140789914134 |+-----------+-----------------------------------+-------------------------------------+--------------+--------------+--------------------+1 row in set (0.00 sec)

74/98

sys

p̲sの情報を⾒やすくするためのビューやストアドファンクション、ストアドプロシージャ

MySQL 5.7.7 and higher includes the sys schema,

a set of objects that helps DBAs and developers

interpret data collected by the Performance

Schema.

https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html

75/98

https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html

sysのインストール(5.6向け)

$ git clone https://github.com/mysql/mysql-sys.gitInitialized empty Git repository in /root/mysql-sys/.git/remote: Counting objects: 3009, done.remote: Total 3009 (delta 0), reused 0 (delta 0), pack-reused 3008Receiving objects: 100% (3009/3009), 1.17 MiB | 466 KiB/s, done.Resolving deltas: 100% (1768/1768), done.

$ cd mysql-sys$ mysql -uroot -p < sys_56.sql

$ mysql -uroot -pmysql> SHOW DATABASES;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || sys |+--------------------+4 rows in set (0.01 sec)

76/98

⾖知識

MySQL 5.7の mysql_install_db には --skip-sys-schema オプションがある

https://dev.mysql.com/doc/refman/5.7/en/mysql-install-db.html#option̲mysql̲install̲db̲skip-sys-schema

-

mysql_upgrade にもあるhttps://dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html#option̲mysql̲upgrade̲skip-sys-schema

-

77/98

statement_analysis, innodb_lock_waits

超⾒やすいこれのためだけに p̲s と sys 有効にする価値があるが、もうさんざん⾔ってきたので詳しくはおググりくださいちなみにこれ以外にも、GithubのREADME が⼀番出⼒例が多くて良いと思う

78/98

https://github.com/mysql/mysql-sys/blob/master/README.md

ps_truncate_all_tables

ストアドp̲s は起動時から統計情報を累積するが、それをリセットするにはp̲sの各テーブルに対してTRUNCATEが必要それを全部まとめてやってくれる、ただそれだけなんだけど便利なストアド

mysql> CALL sys.ps_truncate_all_tables(0);+---------------------+| summary |+---------------------+| Truncated 44 tables |+---------------------+1 row in set (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

79/98

create_synonym_db

ストアドSHOW TABLES FROM .. の結果をそのまま新しいスキーマにCREATE VIEW .. AS SELECT * FROM .. するという雑な作りp_s と i_s を作るのにすごく便利だ

mysql> CALL sys.create_synonym_db('performance_schema', 'p_s');+----------------------------------------+| summary |+----------------------------------------+| Created 87 views in the `p_s` database |+----------------------------------------+1 row in set (0.35 sec)

Query OK, 0 rows affected (0.35 sec)

mysql> use p_sDatabase changed

mysql> SHOW TABLES;..

80/98

MySQLer七つ道具


81/98

Oracle MySQLでベンチマークおじさんしている Dimitri をご存知の⽅︖

82/98

https://twitter.com/dimitrik_fr

「俺が（⽇本の） Dimitriだ」って⽅︖

83/98

Dimitri KRAVTCHUK

84/98

Dimitriおじさん says

85/98


86/98


87/98

Thatʼs right, WE USE OUR

BRAINs88/98

こんなおじさんになりたい

89/98

こんなおじさんにいてほしい

90/98

みなさんのご参加をお待ちしております :)

MyNA ML: ⽇本MySQLユーザ会MySQL Casualʼs Slack: MySQL Casual

91/98

http://mysql.gr.jp/

http://mysql-casual.org/

MySQL Casual Talks vol.10

もっと深く浅く、広く狭くMySQLを使っていこうとい

う趣旨のイベントです。

多⽅⾯から多様なMySQLの使い⽅、運⽤、Tipsなどな

どのTalkを集めたいと思っております。

http://mysql-casual-slackin.herokuapp.com/ から

Slackチャンネルへjoinできますので、ご参加くださ

い。

92/98

https://mysql-casual.connpass.com/event/48473/

え︖ もう補⽋出てるって︖

93/98

やだなあ

まだ3枠余ってるじゃんすか（2017/01/25 18:00現在）

94/98

まあ冗談ではなく

95/98

既に持っている⽅、買ってくれた⽅、よろしければどうぞ :)

@myfinder まで︕96/98

旅は道連れ世は情け

97/98

Questions and/or

Suggestions?98/98

Technology

MySQLerの7つ道具 plus