2016/06/10 GMOテクノロジーブートキャンプ

1. MySQLおじさんの逆襲
とあるイルカのデータベース
2016/06/10
yoku0825の中の⼈
GMOテクノロジーブートキャンプ

2. ＼こんにちは／
yoku0825という名前でインターネットをうろついています
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
好きな⾔葉: 餅は餅屋
1/136

3. MySQL知
ってる⼈︖
2/136

4. MySQL使った
ことある⼈︖
3/136

5. MySQL好
きな⼈︖
4/136

6. 煙草やめるか
MySQLやめるかっ
て⾔われたら⼈間
やめる⼈︖
5/136

7. GMOメディア
サービスはいろいろ
データベース担当
中でもMySQLだけ担当-
6/136

8. 普段のしごと
データベースの増設、リプレース
トラブルシュート
パフォーマンスチューニング
SQLレビュー
Oracle, PostgreSQLもあるけど私はMySQL特化
7/136

9. このセッションを聞いても
MySQLは構築できるようにならないし
SQLも書けるようにならない
他のDBMSのことには⼀切触れない
なので気楽に聞いてください
憶えないといけないことは何⼀つないです-
8/136

10. MySQLとは
永続化可能な
サーバーまたいでアクセスできる
⾔語またいでアクセスもできるよ-
排他・共有ロック機能付きの
グローバル変数のすごいやつ
異論は認める
9/136

11. MySQLとは
永続化可能な
サーバーまたいでアクセスできる
⾔語またいでアクセスもできるよ-
排他・共有ロック機能付きの
グローバル変数のすごいやつ
異論は認める
10/136

12. データの永続化が可能性
トランザクションの特性の⼀つ。Durable。
MyISAM︖ 知らない⼦ですね。-
MySQLが担保してくれるから、アプリケーションはそれほど意識しな
くても
コミットされたデータはクラッシュしても必ず残り
コミットされなかったデータは必ずどこにも残らない
-
暗黙のコミットに注意-
11/136

13. MySQLとは
永続化可能な
サーバーまたいでアクセスできる
⾔語またいでアクセスもできるよ-
排他・共有ロック機能付きの
グローバル変数のすごいやつ
異論は認める
12/136

14. サーバーをまたいだアクセス
TCP/IP接続をサポートしたクライアント(アプリケーション
側)・サーバー(MySQL側)構成
メジャーなプロトコルなので、⾊々な⾔語から同じMySQL
にアクセス可能
⾔語感のデータ型をそんなに意識しなくても、接続ライブラリーが吸
収してくれる
-
13/136

15. MySQLとは
永続化可能な
サーバーまたいでアクセスできる
⾔語またいでアクセスもできるよ-
排他・共有ロック機能付きの
グローバル変数のすごいやつ
異論は認める
14/136

16. 排他制御
トランザクションの機能の⼀つ。MVCC。
あるトランザクションがデータを更新している時に同時アク
セスしていたクライアントには
更新が始まる直前のデータを⾒せるa.
更新中のデータをそのまま⾒せるb.
更新が完全に終わるまで待たせてから⾒せるc.
選べる
更新のタイミング以外でも任意に排他ロックを設定できる-
15/136

17. MySQLの⽴ち位置
app, browser
app, browser
app, browser
app, browser
app, browser
app, browser
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
Database
16/136

18. ここな
app, browser
app, browser
app, browser
app, browser
app, browser
app, browser
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
Database
17/136

19. WEBサーバーとの対⽐
app, browser
app, browser
app, browser
app, browser
app, browser
app, browser
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
WEB, AP
Database
18/136

20. WEBサーバーとDBサーバーの違い
WEB DB
エンドユーザーとの数関係 多対多 多対⼀
データの持たせ⽅ 固有のものを持たせない 共有するものを集約する
冗⻑化 N+1でロードバランス マスターとスレーブは非対称
なのでちょっとコツがいる
データサイズ 静的なもののみなのであまり
変わらない、主にログ
データ次第
スケールアウト戦略 数を増やす シャード（データ分割）する
スケールアップ戦略 CPUとメモリー メモリーとストレージ
19/136

21. データベースの特化した機能
データを安全・確実に保管・取り出しする(トランザクショ
ン)
データに型付け, 取り得る値の制限ができる(制約)
宣⾔的にデータを取り扱う仕組みがある(SQL)
20/136

22. データベースの特化した機能
データを安全・確実に保管・取り出しする(トランザクショ
ン)
データに型付け, 取り得る値の制限ができる(制約)
宣⾔的にデータを取り扱う仕組みがある(SQL)
21/136

23. データベースの特化した機能
データを安全・確実に保管・取り出しする(トランザクショ
ン)
データに型付け, 取り得る値の制限ができる(制約)
宣⾔的にデータを取り扱う仕組みがある(SQL)
22/136

24. データ型
プログラミング⾔語と考え⽅は⼀緒
int型に⽂字列リテラルを突っ込もうとするとエラーにでき
る
設定次第でそうならないのがMySQLのダメなところ。。
しかも「そうならない」⽅がMySQL 5.6までのデフォルト。。。。
-
sql̲mode= STRICT̲TRANS̲TABLESまたは
STRICT̲ALL̲TABLES推奨
-
23/136

25. 制約
UNIQUE制約
同じ値が別の⾏に現れないことの保証-
CHECK制約 MySQLにはないけど5.7でちょっとハックでき
るようになった
データ型の範囲内でも、意に沿わない(計算結果を満たさない)値が記
録されない保証
-
FOREIGN KEY制約
テーブルに親⼦関係を持たせ、「親のない⼦」が存在しない事を保証-
24/136

26. データベースの特化した機能
データを安全・確実に保管・取り出しする(トランザクショ
ン)
データに型付け, 取り得る値の制限ができる(制約)
宣⾔的にデータを取り扱う仕組みがある(SQL)
25/136

27. SQL
SQLより下のレイヤーは隠蔽されている(カプセル化)
⼊⼒も出⼒も集合であるとして扱う
複数カラムでソートとか集約関数がユースケースに含まれて
いる
26/136

28. SQL
SQLより下のレイヤーは隠蔽されている(カプセル化)
⼊⼒も出⼒も集合であるとして扱う
複数カラムでソートとか集約関数がユースケースに含まれて
いる
27/136

29. SQLによる下層の隠蔽
MyISAMやInnoDBといったストレージエンジンのレイヤー
(ファイルフォーマットは全然違う)
MySQLとMariaDBだったり、RDS for Auroraだったり
SQL互換さえあれば、それが実際何者であるかは考えなくて
良い
28/136

30. SQL
SQLより下のレイヤーは隠蔽されている(カプセル化)
⼊⼒も出⼒も集合であるとして扱う
複数カラムでソートとか集約関数がユースケースに含まれて
いる
29/136

31. ⼊⼒も出⼒も集合
RDBMSのデータは連想配列の配列みたいな感じ
なのでクライアント側もそうやって受け取ることが多い気がする-
[
{
'population' => '103000',
'region' => 'Caribbean',
'name' => 'Aruba',
'continent' => 'North America',
},
{
'population' => '22720000',
'region' => 'Southern and Central Asia',
'name' => 'Afghanistan',
'continent' => 'Asia',
},
{
'population' => '12878000',
'region' => 'Central Africa',
'name' => 'Angola',
'continent' => 'Africa',
},
{
'population' => '8000',
'region' => 'Caribbean',
'name' => 'Anguilla',
'continent' => 'North America',
},
{
'population' => '3401200',
'region' => 'Southern Europe',
'name' => 'Albania',
'continent' => 'Europe',
},
..
]
30/136

32. SQL
SQLより下のレイヤーは隠蔽されている(カプセル化)
⼊⼒も出⼒も集合であるとして扱う
複数カラムでソートとか集約関数がユースケースに含まれて
いる
31/136

33. ユースケース
あんな連想配列の配列みたいなやつを
「キー”xxx”の値がAsiaの時だけ、 キー”yyy”の順番に並べる、キ
ー”yyy”が同じ値だったらキー”zzz”の順番で並べる」とか
-
しかも、「なるべく全ループせずに」とかいう無理難題が付いて回る-
SQLは そういう使い⽅をされることを前提に
SELECT .. FROM .. WHERE xxx = 'Asia' ORDER BY yyy, zzz-
すごくシンプルに書ける-
32/136

34. データベースが備えない機能
無限のストレージ
無限の計算量
エラーにならないトランザクション
いい感じの⽂字列操作
33/136

35. データベースが備えない機能
無限のストレージ
無限の計算量
エラーにならないトランザクション
いい感じの⽂字列操作
34/136

36. ストレージサイズ
100バイトのデータを格納するには100バイトの容量を使う
UTF8ではほとんどの⽇本語⽂字は 3バイト-
インデックスは ソート済みのデータの複製 。データそのものとは別
に容量を必要とする
-
それ以外にもトランザクション⽤のREDOログ、UNDOログ
が必要
レプリケーションのために増分ログ（バイナリーログ）の容
量も要る
35/136

37. つまり
プレーンテキストより余程容量を必要とする
トランザクションによる保護が必要な場⾯以外でMySQLに
なんでも詰め込むのはかなりの勢いで間違い
個⼈的にはホットログだけトランザクション保護でMySQLに⼊れて、-
コールドログはMySQLからダンプしちゃって-
SQLで集計したくなった時だけ戻せば良いと思う-
36/136

38. データベースが備えない機能
無限のストレージ
無限の計算量
エラーにならないトランザクション
いい感じの⽂字列操作
37/136

39. 計算量問題
WHERE 句でフィルタリング、 ORDER BY 句でソート、 GROUP
BY 句でグルーピングができる
select̲listに非集約関数も書ける-
もちろん便利に使うべき-
ただし、フィルタリングするにもソートするにも関数を通す
にも、必ずCPUを使って計算する
38/136

40. 誰が計算するのか問題
MySQLの中では⼤きく分けて2つのコンポーネントが計算す
る
エグゼキューター-
ストレージエンジン-
格納する時に計算するか取り出す時に計算するか-
MySQLの中でやるか外でやるか
外でやるにしても、サーバーサイドでやるのかクライアントサイドで
やるのか
-
なんでもかんでも1つのSQLで終わらせるのが正しいとは限
らない
39/136

41. データベースが備えない機能
無限のストレージ
無限の計算量
エラーにならないトランザクション
いい感じの⽂字列操作
40/136

42. エラーにならない訳がない
トランザクションの役割
コミットされたデータはクラッシュしても必ず残り-
コミットされなかったデータは必ずどこにも残らない-
ことを保証する-
では、「必ず残す」ことが保証できないシチュエーションで
は︖
コミットを成功させては いけない-
41/136

43. データが必ず残ることを保証する訳じゃない
コミットの成否とデータの有無が⼀致することを保証する
デッドロック検知でロールバックが嫌だ︖
ロールバックするのが正常系
データが巻き戻ってエラーになるのと
エラーにならずにデータがどこかおかしくなるの
どっちがお好み︖
-
42/136

44. データベースが備えない機能
無限のストレージ
無限の計算量
エラーにならないトランザクション
いい感じの⽂字列操作
43/136

45. ⽂字列操作
データベースは「 データの保管と取り出し に特化した アプ
リケーション」
Twitterアプリで効率よくラーメンが注⽂できないのと⼀緒で、 設計
目的以外の何か に対して効率よくは動けない
-
⽂字列関数はいくつかあるしLIKE演算⼦もあるけど、得意
な訳じゃないというか正直苦⼿な部類
誰がCPUを使うのか問題にも通じる-
44/136

46. ここまで
のまとめ
45/136

47. ここまでのまとめ
データベース（RDBMS）は便利
だけど万能じゃない
得意なことと不得意なこと
MySQLに限って⾔えば、得意なことと それ以外-
ナントカとハサミは使いよう :)
46/136

48. 意外とデータ
ベース⼀般論
になっていた
47/136

49. 肩があったまって
きたところで
MySQLの話します
48/136

50. MySQLの
正しい発⾳
49/136

51. マイエスキューエル
The official way to pronounce “MySQL” is “My Ess
Que Ell” (not “my sequel”), but we do not mind if
you pronounce it as “my sequel” or in some other
localized way.
http://dev.mysql.com/doc/refman/5.7/en/what-is-
mysql.html
50/136

52. MySQLの
名前の由来
51/136

53. Myちゃん
MySQL is named after co-founder Monty
Wideniusʼs daughter, My.
http://dev.mysql.com/doc/refman/5.7/en/history.html
ただしMyちゃんの名前の発⾳は ミィ
52/136

54. MariaDBの
名前の由来
53/136

55. Mariaちゃん
MariaDB continues this tradition by being named
after his younger daughter, Maria.
https://mariadb.com/kb/en/mariadb/why-is-the-
project-called-mariadb/
54/136

56. MySQLのロゴ
自重
55/136

57. このイル
カの名前
56/136

58. サキラまたはサキーラ
The name of the MySQL Dolphin (our logo) is
“Sakila,”
http://dev.mysql.com/doc/refman/5.7/en/history.html
57/136

59. MySQLのロゴ
実は利⽤規定が厳しい
というかまず使えない
MySQL :: Logo Usage Guidelines
58/136

60. 実はもう⼀種類ある
自重
59/136

61. MySQLはい
つからある︖
60/136

62. MySQLの歴史
1995年⽣まれ（公式な歴史には残ってないぽい）
去年、20周年パーティーやってた
FOSDEM 2015 with MySQL & MySQL 20 years anniversary celebration!
-
最初の⽇本語対応は 1997年11⽉の3.21.x
最古のリリースノートは1999年7⽉の3.23.0-Alpha
61/136

63. :（;ﾞﾟʼωﾟʼ）:
MySQLより年下の
⼈いる︖
62/136

64. ちなみにOracle DBは1977
年が最初のリリース
Postgres(Not
PostgreSQL)の初期バージ
ョンが1986年
63/136

65. MySQLの親
Michael Monty Widenius とあと何⼈か（知らない）
Montyが⽴ち上げた「MySQL AB」を⺟体として開発者を集
める
64/136

66. Oracleに買われて
からライセンスが
えげつなくなっ
た︖
65/136

67. デュアルライセンスモデル
GPL
GPLでいいならタダでいいよ-
商⽤ライセンス
GPLでコードを配布したくない場合はお⾦を払ってね-
MySQL ABの頃からずっとこう
MySQL AB時代の⽅がえげつない訴訟をしていたかも-
PHPと喧嘩してみたり-
66/136

68. ちなみにMariaDB
やPercona
Serverは(お⾦を
払っても)GPL
67/136

69. MySQLの歴史
2001年 MySQL 3.23製品リリース
2003年 MySQL 4.0製品リリース
2004年 MySQL 4.1製品リリース
2005年 MySQL 5.0製品リリース＆Innobase買収
68/136

70. Innobase︖
69/136

71. Innobase
当時のInnoDBストレージエンジンの開発元
InnoDBのMySQLへのバンドルは4.0から
当時のMySQLのメインストレージエンジンはMyISAM（トランザクシ
ョン非対応）
-
「MySQLはトランザクションに対応していない」を挽回するための期
待の星だった
-
しかも買収元が
70/136

72. ＿⼈⼈⼈⼈⼈＿
＞ Oracle ＜
￣Y^Y^Y^Y￣
71/136

73. Innobase買収
契約上は、「これまでと同様のライセンスでMySQL ABに
InnoDBを出荷する」だったらしい
とはいえ誰もが「OracleはInnoDB(= MySQLのトランザク
ションの可能性)を潰す」と思った
BDBストレージエンジン︖ PBXT︖ Falcon︖ SolidDB︖
ちなみにBDB作ってたSleepycatも2006年にOracleに買収されてる-
「OracleはDB製品を2つ持っている」は間違い。もっといっぱいある-
なんかどっかで聞いたことのある話
72/136

74. MySQL 5.0
最も⻑い期間メンテナンスされたMySQL
5.0.15(2005/10)〜5.0.96(2012/3)-
この頃までは商⽤版とGPL版でコードベースが分かれていた
（商⽤版にしかないパッチバージョンが存在する）
73/136

75. MySQL
5.0.96
なんて読む︖
74/136

76. MySQL 5.0.96
ごー てん ぜろ（れい） てん きゅーろく（きゅーじゅーろ
く）
ごー ぜろ きゅーろく（きゅーじゅーろく）
あるいは他に
75/136

77. 5.0.96の意味
5
メジャーバージョン番号
0
リリースレベル
96
リリースシリーズ(メジャーバージョン番号とリリースレベル)内でのバージ
ョン番号
http://dev.mysql.com/doc/refman/5.7/en/which-
version.html
76/136

78. オレオレ認識
5.0
メジャーバージョン（正しくはリリースシリーズ）
96
マイナーバージョン
77/136

79. リリースシリーズ ≒ メジャーバージョン
アップグレードの後⽅互換性の単位
新機能追加の単位
だった-
ドキュメントの分冊の単位
78/136

80. 内部的には
#define MYSQL_VERSION_ID 50096 // 5.0.96
#define MYSQL_VERSION_ID 50173 // 5.1.73
#define MYSQL_VERSION_ID 50709 // 5.7.9
#define MYSQL_VERSION_ID 100112 // 10.1.12(MariaDB)
79/136

81. バージョン番号
3桁にできない
ギリギリセーフ
MariaDBが10.0系をローンチした時にMySQL側が6桁バー
ジョンIDを考慮してなかったので互換性が壊れた
今は確か直した様な気がする-
80/136

82. 話を戻す
と
81/136

83. ここでMySQL AB買収
2008/02 Sun MicrosystemsがMySQL ABを10億ドルで買
収
ちなみにOracleのSun買収額は74億ドル-
そのうちどれだけがMySQLの価値だったのかは知らない-
当時としては破格
82/136

84. ちなみに
MySQL ABの製品サポートライフサイクルは3年だった
MySQL 5.0のリリースは2005/10
間にMySQL AB買収 2008/02
MySQL 5.1のリリースは2008/11
83/136

85. ライフサイクル切
れるのに次のバー
ジョンが出てない
ｗｗｗ
84/136

86. MySQL 5.1
5.1.30(2008/11)〜5.1.73(2013/12)
Sun時代最初で最後のリリース
Storage Engine APIの公開（プラガブルStorage Engine）
MySQLにバンドルされているInnoDB（ビルトイン
InnoDB）がなかなかマージしてくれない性能改善を、
InnoDBのフォーク（プラグインInnoDB）にどんどん追加
MySQL 5.5ではビルトインInnoDBが廃⽌されてプラグインInnoDB
がメインのInnoDBになった
-
85/136

87. ここでMonty離脱
2009/02 Monty Program設⽴＆MariaDB開発スタート
「Oracleに嫌気がさしてフォークした」は間違い-
このころはSunの協⼒を得てMariaストレージエンジン（現
在のAriaストレージエンジン）の開発がメインだったとか
夢のトランザクショナルMyISAM-
86/136

88. そしてSun買収
2010/01 OracleによるSun買収
別にMySQLに興味はなさそう。Sun買ったらたまたまつい
てきた、みたいな。
奇しくもここでまた旧Innobaseと再開
87/136

89. MySQL 5.5
5.5.8(2010/12)〜5.5.50
Oracle時代最初のリリース
ということは開発の⼤半はSun時代-
InnoDBがデフォルトのStorage Engineに
88/136

90. MySQL 5.6
5.6.10(2013/02)〜5.6.31
「今までで最⾼のMySQL」
Facebookも5.1の次に選んだのはコレ
Percona拡張やFacebook拡張が結構取り込まれた
「MyISAMでできてInnoDBでできないことをなくす」
89/136

91. MySQL 5.7
5.7.9(2015/10)〜5.7.13
「There are over 150 new features」「Secure by
default」
InnoDBが5.6よりもカリカリにチューニングされてる
運⽤に便利なオンライン系の操作が追加された
良いMySQLだと思うんだけど罠い
See https://yoku0825.blogspot.jp/search/label/5.7
90/136

92. MySQL 5.7
2013/02 MySQL 5.6.10 GA
2013/04 MySQL 5.7.1 DMR11
2015/03 MySQL 5.7.6 DMR16
2015/04 MySQL 5.7.7 RC
2015/08 MySQL 5.7.8 RC
2015/10 MySQL 5.7.9 GA
2015/12 MySQL 5.7.10 GA
2016/02 MySQL 5.7.11 GA
2016/04 MySQL 5.7.12 GA
2016/06 MySQL 5.7.13 GA
91/136

93. MySQL 5.7
2015/04 MySQL 5.7.7 RC
ここまではまあいい
2015/08 MySQL 5.7.8 RC
JSON型, virtual generated columnの拡張, InnoDB Page Compression
2015/10 MySQL 5.7.9 GA
innodb_default_row_format, JSON -> operator, innodb_numa_interleave
2015/12 MySQL 5.7.10 GA
Bug Fix
92/136

94. MySQL 5.7
2016/02 MySQL 5.7.11 GA
InnoDB Tablespace Encryption
2016/04 MySQL 5.7.12 GA
X Plugin
2016/06 MySQL 5.7.13 GA
JSON ->> operator
93/136

95. MySQL 5.7
2015/04 MySQL 5.7.7 RC
ここまではまあいい
2015/08 MySQL 5.7.8 RC
新機能!!
2015/10 MySQL 5.7.9 GA
新機能!!
2015/12 MySQL 5.7.10 GA
Bug Fix
94/136

96. MySQL 5.7
2016/02 MySQL 5.7.11 GA
新機能!!
2016/04 MySQL 5.7.12 GA
新プラグイン!!
2016/06 MySQL 5.7.13 GA
新演算⼦!!
95/136

97. GAとは何
だったのか
96/136

98. MySQL 5.7.12 –
Part 1: More than
a Maintenance
Release
97/136

99. 開き直った:
(;ﾞﾟʼωﾟʼ):
98/136

100. MySQL 5.7.12 –
MySQL
Document Store
– YouTube Video
99/136

101. ノリノリだな
おまいら:
(;ﾞﾟʼωﾟʼ):
100/136

102. リリースシリーズごとの状況
MySQL 5.1.73 and Earlier (End of Product Lifecycle)
MySQL 5.5.50 (Previous GA, Extended Support)
MySQL 5.6.31 (Previous GA, Premier Support)
MySQL 5.7.13 (GA, Premier Support)
MySQL 8 (︖︖︖)
101/136

103. リリースシリーズごとの状況
MySQL 5.1.73 and Earlier (End of Product Lifecycle)
MySQL 5.5.49 (Previous GA, Extended Support)
MySQL 5.6.30 (Previous GA, Premier Support)
MySQL 5.7.12 (GA, Premier Support)
MySQL 8 (︖︖︖)
102/136

104. MySQL 8.0（︖︖︖）
もともとMySQL 5.8として開発されていたブランチ
目⽟はnew Data Dictionary と Group Replication
newDDは5.8のブランチにマージされた模様なのは観測した-
GRはまだっぽい-
まだDMRも出てない
Eightって呼ばれてるけど、8.0なのか8なのかよくわからな
い
103/136

105. X Pluginと合
わせてどこに⾏
くのやら。。
104/136

106. メインストリーム以外のMySQL
Percona Server
MariaDB
WebScaleSQL
Facebook MySQL
Twitter MySQL
AliSQL
..
105/136

107. Oracleによるユーティリティー
MySQL Workbench
MySQL Utilities
MySQL Fabric
MySQL Router
MySQL Shell
106/136

108. エコシステム
MHA for MySQL
Percona Toolkit
innotop
Galera Cluster
Mroonga Storage Engine
Q4M Storage Engine
..
107/136

109. データベースは枯
れたバージョンを
使うのがいいけど
108/136

110. エコシステムに⾒放されな
い程度には追随した⽅がい
い
エコシステムはもともと他⼈の作った
船に乗せてもらうということ
109/136

111. とはいえ
そんなにMySQLの最新情報ばっかり追いかけらるわけでも
ない
他にやることはいっぱいある-
エコシステムは⽣まれては消えていく
新機能、 “試してみた” ネタだけじゃ物⾜りない
踏み抜かれた地雷や運⽤の闇は蜜の味
110/136

112. 学習の⾼速道路の話は本当にそうだと思う
この10年のITの進化とインターネットの普及によって
将棋の世界の何がいちばん変わったか。
⽻⽣さんは簡潔にこう⾔った。
「将棋が強くなるための⾼速道路が⼀気に敷かれたとい
うことだと思います。でも、その⾼速道路を⾛り切った
ところで⼤渋滞が起きています」
インターネットの普及がもたらした学習の⾼速道路と⼤渋滞
4 ⽉にエンジニアとなった⼈たちに知っておいてもらいたいこと-
111/136

113. 渋滞を抜け出す選択肢︖
ユーザーとしての活動
イマココ-
デベロッパーとしての活動
ただしこれはMySQLではできない-
パトロンとしての活動
個⼈じゃ難しいかも-
他にもあるとは思う
112/136

114. ⽇本MySQLユーザ会
⽇本MySQLユーザ会（略称: MyNA = MySQL Nippon
Association）
まいな、と読みます。-
http://mysql.gr.jp/
113/136

115. さっきから（︖）
背景にいる
この⼦ ⇒
114/136

116. マイナくん（仮称）がいるじゃろ︖
⽇本MySQLユーザ会のロゴ
Mynaという⿃が実在してて、九官⿃の仲間らしい-
このロゴは使って⼤丈夫なやつ
115/136

117. これを
116/136

118. こうじゃ
このイラストも使って⼤丈夫なやつ
117/136

119. ⽇本MySQLユーザ会
現在の主な活動は ML での意⾒交換です。時々オフ会も
あるかもしれませ ん :-)
MySQL に興味がある⽅はどなたでも⼊会できます。会
費はありませんし、 退会も⾃由です。
http://mysql.gr.jp/frame/myna/index.php
118/136

120. ⽇本MySQLユーザ会
MLなのでまあレスポンスは速くない
というかぶっちゃけ流量が死んでる
OSCとかMyNA会の告知くらいしか流れてこないかも-
とはいえ⽇本MySQL界の知識⼈が結構集まっているので
技術的な疑問とか投げてみると盛り上がるかも知れない
119/136

121. MySQL Casual
perl-casualのコンセプトに触発され、もっと深く浅
く、広く狭くMySQLを使っていこうと思っている趣旨
の⼈とのつながりを作っていくための緩めのコミュニテ
ィです。
http://mysql-casual.org/
120/136

122. MySQL Casual
slackin でメールアドレスを登録すると⾃動で招待メー
ルが⾶ぶようになっています。 また、Slackでの過去の
チャット履歴は slackarchive で読むことができます。
http://mysql-casual.org/mysql/casual/2016/06/07/
how-to-join-mysql-mysql-casual.html
121/136

123. MySQL Casual
Slackベースだけどそんなに雑談雑談してない。
こっちはWEB界隈のMySQL使いが集まっている
MyNA会以外の勉強会の告知もたまに流れてくる
122/136

124. コミュニティーに属するということ（広義）
他者との知⾒の共有
ユーザー同⼠だったり、ユーザーとデベロッパーの間だったり-
⼈とのつながり
気分転換
123/136

125. コミュニティーに属するということ（狭義）
秘密の情報の共有
次なるコミュニティー参加へのお誘い
発表駆動学習
124/136

126. まあ、そん
なことより
125/136

127. 楽しい
126/136

128. MySQLの話す
るの 楽しい で
す
127/136

129. 地雷友達
⼤事
128/136

130. Oracle ACE Program
Oracle ACEs have proven expertise across the
entire Oracle stack. Following the content they
publish, share, and discuss is the best way to stay
up to speed with Oracle technology and best
practices.
http://www.oracle.com/technetwork/community/
oracle-ace/index.html
Oracle ACE Details
129/136

131. MySQL 5.7 Community Contributor Award
Program
Tsubasa Tanaka, the MySQL ACE for his very
active role in the Japanese community
MySQL 5.7 Community Contributor Award
130/136

132. MySQL Serverのプロダクトマネージャーから
We would like to thank Tsubasa Tanaka for filing
bug 77277 – default̲password̲lifetime should be
set 0 as implicit default value
An update on default̲password̲lifetime
MySQL 5.7の罠があなたを狙っている
131/136

133. Etc.
カンファレンスのCfP通りやすかったり
連載とか特集とか誘ってもらえたり
憧れのMySQLerに会えたり
キャラクターを勝⼿に擬⼈化しても誰にも怒られなかったり
132/136

134. TDD
TDD(Twitter Driven Datsu-Syoshinsya) / Twitter駆動脱
初⼼者 #yapcasia // Speaker Deck
LT / TDD / Yudai Suzuki - YouTube
133/136

135. コミュニティー忙
しくしすぎて仕事
つらくならないよ
うに
134/136

136. ⽤法・⽤量を守
って、楽しい
MySQLライフを
135/136

137. Any Questions
and/or
Suggestions?
136/136