とあるイルカのデータベース

2018/07/06 GMOテクノロジーブートキャンプ

Transcript

1. とあるイルカのデータベース コイツ、案外よくできてる 2018/07/06 yoku0825 GMOテクノロジーブートキャンプ
2. おことわり この資料で述べられる見解はyoku0825の中の人のノリによ るものであり、所属する組織または所属しない組織の意見を 一切合切代表するわけがありません この資料を読んだりセッションを聞いたりしてもたぶんSQL を書けるようにはなりません ざっくりわかりやすくするために、いくつか簡単なモデルで 説明しているところがあります。鵜呑みにはできません 1/119
3. なので 2/119
4. テキトーに聞 いといてくだ さい 3/119
5. MySQL触った ことある人？ 4/119
6. MySQL で きる 人？ 5/119
7. MySQL知 らない人？ 6/119
8. MySQLより 年下の人？ 7/119
9. こんな画面触ったことある人？ 8/119
10. こういうやつの方が好きな人？ 9/119
11. MySQL好 きな人？ 10/119
12. 三度の飯より MySQLが好き な人？ 11/119
13. ( ´∀｀)ﾉ お れはごはんの ほうがすき 12/119
14. MySQL #とは 世界でもっとも普及している、オープン ソース データ ベース https://www.mysql.com/jp/ 13/119
15. 我々の生活の中でのMySQL #とは 永続化可能な サーバーまたいでアクセスできる 排他・共有ロック機能付きの グローバル変数のすごいやつ 異論は認める MySQLおじさんの逆襲 14/119
16. MySQL #とは グローバル変数のすごいやつ 異論は認める の 保管 と 取り出し に 特化 した アプリケーション 特化している以上、それ以外のことは（できなくはなかった としても）性能が落ちる ただしトーストは焼ける 15/119
17. ただしトーストは焼ける Fixing MySQL Bug#2: now MySQL makes toast! - Percona Database Performance Blog 16/119
18. この番組（？）では グローバル変数のすごいやつを自前で実装しようと思ったら アプリケーション側で何をしなければならないのか InnoDBがどんなことをしているのか を説明できたらいいなと思う 合言葉は「コイツ、案外よくできてる」 17/119
19. ＼こんにちわ／ yoku0825＠GMOメディア株式会社 オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ←new!! ‐ MySQL Casual ‐ 18/119
20. (知らないうちに ) MySQLがやっ てくれていること 19/119
21. MySQLと上手く付き合うには 知らないうちにMySQLがやってくれていること MySQLはやってくれないこと それぞれを知り、やってくれることは任せて、やってくれな いところをアプリケーション側で実装する 20/119
22. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 21/119
23. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 22/119
24. データの永続化 コミットされたデータは（ストレージが吹っ飛ばない限り） 必ずそこに残ることを保証する これを自前で実装するとしたらどうすればいい？ 23/119
25. データの永続化 24/119
26. データの永続化 コミットの成功応答を遅延させることで「成功=必ず残って いる」を表現する これ単体だとまあなんとかなる 原子化と分離が絡んでくるとややこしくなる ‐ 25/119
27. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 26/119
28. 操作の原子化 トランザクションといえば「2つ以上のステートメントをあ たかも1つの操作として…」と表現されることが多いけれど 実際は1ステートメントの処理内容でも原子性を意識しない といけない 27/119
29. 操作の原子化 28/119
30. 操作の原子化 書き込みに失敗してエラー応答を返すなら、書き込み途中の ものが見えてはいけない INSERTが失敗したなら空の行を ‐ UPDATE/DELETEが失敗したなら更新前の行を ‐ 返さないといけない ‐ とはいえワンアクションで1カラム1GBのデータを書くこと はできない 29/119
31. 操作の原子化 30/119
32. 操作の原子化 1レコード = 1ファイルならこれで何とかなるかも？ 「あるいはレコードが固定長なら…」 ‐ 正気に戻れ！ ‐ 31/119
33. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 32/119
34. トランザクションの分離/一貫性の保証 たとえば100行の結果セットがあって 先頭から50行読み込んだところで 51行目を更新するトランザクションがコミットされたとし たら何が起こる？ もちろん、更新が適用される前の行を返すんだけれども、ど うやってそれを表現する？ 33/119
35. トランザクションの分離/一貫性の保証 結果セットを読み込んでいる最中は当該の範囲に対する更新 をブロックする たとえば transaction_isolation = SERIALIZABLE はそんな動きにな る ‐ MyISAMという古いストレージエンジンもテーブル単位でロックする ことでこれを防ぐ ‐ 34/119
36. トランザクションの分離/一貫性の保証 更新前の値を捨てずに取っておいて、必要なら読み取り側が 更新前の値を参照しにいく 「現在の行」が「自分の1つ前のバージョン」に対する参照を持つ ‐ たとえばPostgreSQLは追記型アーキテクチャーなので、新しく追加 した側の行にそれを持たせればいい ‐ MySQLのInnoDBはインプレースなアーキテクチャーなので、元のデ ータをUNDO領域にコピーしている ‐ 35/119
37. トランザクションの分離/一貫性の保証 auto row= get_row(); switch (isolation_level) { case READ-COMMITTED: while (row) { if (row.has_committed) return row; else row->prev_version(); } case REPEATABLE-READ: while (row) { if (row.has_committed && row.commit_time < transaction_started) return row; else row->prev_version(); } ...; } 36/119
38. トランザクションの分離/一貫性の保証 READ-COMMITTED ステートメント が開始された時点でコミット済みの行を読み込む ‐ REPEATABLE-READ トランザクション が開始された時点でコミット済みの行を読み込む ‐ トランザクションの先頭で重い集計クエリーを流している間に更新が あっても、その間の更新を後続の集計クエリーは読まずに済む ‐ 論理バックアップでも使われる ‐ 37/119
39. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 38/119
40. インデックスのメンテナンス インデックスとは「構造化されたデータの部分集合」 辞書とその索引に例えた時に 辞書本文のページが増減したら、索引もそれに合わせて作り直さなけ ればならない ‐ 場合によっては「構造」の中でのメンテナンスが必要 B-Treeで中間のリーフノードを追加し続けると…？ ‐ しかも「永続性」「原子性」「分離性/一貫性」を保ちつつ ‐ 39/119
41. (知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 40/119
42. I/O量の削減 ここまでのものを愚直に再発明したとしたら、1行更新する だけで一体何回のfsyncが必要になるんだ？ fsyncはストレージI/Oの中でも最も遅い類 ‐ 特にハードディスクでは致命的に遅い ‐ 100GBのテーブルから1行探すために、100GBをスキャンす る訳にはいかない I/O効率、キャッシュ効率、局所性… ‐ 圧縮、展開、暗号化とかまで考え出すと…？ ‐ 41/119
43. I/O量の削減 効率を高めるための理論、実装がそれぞれ議論されている アカデミックな場から市場に降りてくるまでの時間差はあるけれども ‐ 自前でやるとしたらメモリー管理やI/O管理まで手を伸ばせ る言語に縛られることになる 我々はRDBMSという巨人の肩に乗っかって仕事をすること ができる 42/119
44. (知らないうちに) MySQLがやってくれていること 自分で再発明するとなるとかなり大変 「MySQLはSQLをしゃべるKVS」？ ‐ 「最近のKVSはずいぶん色んな機能を求められるんですね」 MongoDBもマルチドキュメントトランザクションサポートしたらしいし ‐ やってくれるとはいえ要らない機能があるなら、それを持た ない代わりに高速化された何かを選ぶことができる 命題: トランザクションの分離性は要らないからredisを使う ‐ 命題の逆: redisを使うからトランザクションの分離性は捨てるか別 のところで担保しないといけない ‐ 43/119
45. MySQLができること、できないこと、苦手なことを知る 任せた方が楽なものはMySQLに任せて再発明を避ける できないこと、苦手なことを無理矢理MySQLに押し付けて も幸せにはなれない MySQLを捨てて得られるものと得られないものを知ってデ ータストアを楽しく使う 44/119
46. ひとやす み 45/119
47. InnoDB #とは 46/119
48. MySQLの内部処理 47/119
49. MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 48/119
50. MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 49/119
51. InnoDB #とは InnoDBストレージエンジン MySQL 5.5とそれ以降でデフォルトのストレージエンジン 50/119
52. InnoDBのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.1 InnoDB 入 門 51/119
53. (比較用) MyISAMのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.2 MyISAM ス トレージエンジン 52/119
54. ストレージエンジンが違うと サポートされる機能が変わる 性能特性もガラっと変わる 迷ったらInnoDB というか迷わずInnoDB その他のストレージエンジンを正しく扱えるのはMySQLニ ンジャだけだと心得る 裏を返すとその他のストレージエンジンも正しく扱えるようになれば MySQLニンジャだ ‐ 53/119
55. 取り敢えず押さえておきたいInnoDBのコンポーネント バッファプール InnoDBログファイル テーブルスペースファイル UNDOログ 54/119
56. InnoDBの読み取り バッファプールの中から読み取り対象の行が含まれているペ ージを探す バッファプール上になければテーブルスペースファイルから 読み取り対象のページを読み出してバッファプールに載せる バッファプールに載ったページのバージョンはトランザクシ ョン分離レベルを満たすか？ 満たさない場合はUNDOログから以前のバージョンのページをバッフ ァプールに転送し、再評価する ‐ トランザクション分離レベルを満たすバージョンのページが 手に入ったら対象の行を上位のレイヤーに返す 55/119
57. InnoDBの書き込み バッファプールの中から更新対象の行が含まれている （INSERTした時に含まれるようになる）ページを探す バッファプール上になければテーブルスペースファイルから 書き込み対象のページを読み出してバッファプールに載せる UNDOログに更新前の行の情報を書き込む バッファプール上のページを更新する InnoDBログに更新情報を書き込む 56/119
58. InnoDBの書き込み バッファプールからテーブルスペースファイルへの反映は 非同期 InnoDBログはシーケンシャルライトになるように最適化されている が、 ‐ テーブルスペースファイルへの書き込みはランダムライトになりがち ‐ デフォルトでダブルライトするので、同期でランダムライト x 2だと レイテンシーが ‐ 57/119
59. InnoDBの書き込み InnoDBログへのシーケンシャルライト + オンメモリーのバ ッファプール更新を同期、ランダムライト（かつダブルライ ト）のテーブルスペースファイルへの書き込みを非同期化す ることでパフォーマンスとI/Oの節約 読むときは優先的にバッファプールから読むので、バッファプールか ら追い出される(=その後のアクセスはテーブルスペースファイルか ら読まれるようになる)時までランダムライトを遅延させられる ‐ ダーティーページが更に更新された場合、フラッシュが必要なのは 「最後の更新後のページ」なので、フラッシュ回数が更に減らせる ‐ 書き込みとクラッシュの話についてはもう数ページ先で 58/119
60. 読み込み中の書き込み 読み取り中に次にフェッチする行が更新された場合、UNDO ログから以前のバージョンをバッファプールに転送して読み 続けられる ロックを取ることなく読み取りと書き込みが共存できる ‐ 流石にバッファプールのページを書き換える一瞬はラッチで排他制御 されるけれどメモリー上なので時間は非常に短い ‐ 読み取りに必要なのはバッファプール, テーブルスペースフ ァイル, UNDOログのみなので、InnoDBログは排他ロック を使って直列化できる 59/119
61. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced SQL実行 まだ Updating Copied Synced COMMIT待ち Writing/ Syncing Updated Copied Synced COMMIT完了 Synced Synced Copied Outdated (非同期) Synced Synced Copied/ Purged Synced 60/119
62. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced この時点で他のトランザクションがSELECTした場合、バッ ファプールの情報を読むため問題ない この時点で他のトランザクションが書き込もうとした場合は ロック待ちになる この時点でクラッシュした場合、中途半端なUNDOログを捨 てればステートメントはなかったことにできるので問題ない 61/119
63. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL実行 まだ Updating Copied Synced この時から他のトランザクションはバッファプールの更新後 のページに書かれた ロールバックポインター を読んで、 UNDOログから前のバージョンを取り出すようになる この時点でクラッシュした場合、UNDOログの消し込みだけ でいい（バッファプールはオンメモリーなのでクラッシュし たら消える） 62/119
64. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT待ち Writing/ Syncing Updated Copied Synced 他のトランザクションからのSELECTは同じ クラッシュも書きかけのInnoDBログを捨てれば操作前の状 態に戻れる 63/119
65. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT完了 Synced Synced Copied Outdated ここでコミットが終了するので、他のトランザクションは更 新された新しいバッファプールのデータを読む（またはトラ ンザクション分離レベルに応じてUNDOを読む） コミットされた時点でロックが外れるので、他の書き込みト ランザクションも動き始められる バッファプールとInnoDBログさえ排他にロックできればいいので、 テーブルスペースファイルが同期されるのを待つ必要はない ‐ ここでクラッシュした場合、更新前のテーブルスペースファ イルの値と、更新差分であるInnoDBログを使って、クラッ シュ前にバッファプールに載っていたページを再計算する 64/119
66. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル (非同期) Synced Synced Copied/ Purged Synced コミット完了以後、他のトランザクションからの参照, 書き 込みと永続性に関しては変化はない クラッシュリカバリーの時間を短縮するため、バッファプー ルの値をテーブルスペースファイルにフラッシュして、再計 算が必要なページの数を減らす 65/119
67. テーブルスペースファイルとInnoDBログの関係 コードとパッチみたいな感じ？ ある時点のコードと、それ以降の全てのパッチがあれば最新のコード に復元できる ‐ パッチの数が多すぎると復元に時間がかかるので、ある程度のところ でマージして復元にかかる時間を短縮する ‐ 66/119
68. InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced SQL実行 まだ Updating Copied Synced COMMIT待ち Writing/ Syncing Updated Copied Synced COMMIT完了 Synced Updated Copied Outdated (非同期) Synced Synced Copied/ Purged Synced 67/119
69. InnoDBのクラスターインデックス (セカンダリー) インデックスが二重構造になっている セカンダリーキーが示す先はプライマリーキーの値 ‐ セカンダリーキーで検索する => プライマリーキーの値を得る => プライマリーキーで検索する => 結果が返る ‐ 68/119
70. MyISAMのインデックス方式 INSERT INTO t1 VALUES (1, 'one', 'ichi'); |1|:|o|n|e|:|i|c|h|i| PRIMARY 1 => offset 1 SECONDARY one => offset 1 69/119
71. MyISAMのインデックス方式 INSERT INTO t1 VALUES (2, 'two', 'ni'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i| PRIMARY 1 => offset 1 2 => offset 11 SECONDARY one => offset 1 two => offset 11 70/119
72. MyISAMのインデックス方式 INSERT INTO t1 VALUES (3, 'three', 'san'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i|3|:|t|h|r|e|e|:|s|a|n| PRIMARY 1 => offset 1 2 => offset 11 3 => offset 19 SECONDARY one => offset 1 three => offset 19 two => offset 11 71/119
73. MyISAMのインデックス方式 UPDATE t1 SET val = 'nii' WHERE num = 2; |1|:|o|n|e|:|i|c|h|i| | | | | | | | | |3|:|t|h|r|e|e|:|s|a|n|2| |:|t|w|o|:|n|i|i| PRIMARY 1 => offset 1 ---- 2 => offset 30 3 => offset 19 SECONDARY one => offset 1 three => offset 19 ---- two => offset 30 72/119
74. MyISAMのインデックス方式 関係ないカラムをいじっただけでも、物理的な行配置が変わ るとインデックスを更新しないといけない 73/119
75. InnoDBのクラスターインデックス INSERT INTO t1 VALUES (1, 'one', 'ichi'); |1|:|o|n|e|:|i|c|h|i| PRIMARY 1 => offset 1 SECONDARY one => 1 74/119
76. InnoDBのクラスターインデックス INSERT INTO t1 VALUES (2, 'two', 'ni'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i| PRIMARY 1 => offset 1 2 => offset 11 SECONDARY one => 1 two => 2 75/119
77. InnoDBのクラスターインデックス INSERT INTO t1 VALUES (3, 'three', 'san'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i|3|:|t|h|r|e|e|:|s|a|n| PRIMARY 1 => offset 1 2 => offset 11 3 => offset 19 SECONDARY one => 1 three => 3 two => 2 76/119
78. InnoDBのクラスターインデックス UPDATE t1 SET val = 'nii' WHERE num = 2; |1|:|o|n|e|:|i|c|h|i| | | | | | | | | |3|:|t|h|r|e|e|:|s|a|n|2| |:|t|w|o|:|n|i|i| PRIMARY 1 => offset 1 ---- 2 => offset 30 3 => offset 19 SECONDARY one => 1 three => 3 two => 2 77/119
79. InnoDBのクラスターインデックス インデックスに関係ないカラムの更新に影響を受けなくなる インデックスの更新回数が減る = I/O回数が減る ‐ インデックスが増えれば増えるほど顕著に ‐ 78/119
80. MySQLの面白いところ 実ファイル, バッファ, トランザクションなどを管理する部 分 がコンポーネントとして切り離されている トランザクション非対応なストレージエンジンを選んで性能を上げ る, 新しい機能を追加する ‐ レイテンシーよりも容量や書き込み回数を重視したストレージエンジ ンを選べる ‐ Be a MySQLニンジャ 79/119
81. MySQLの面白いところ コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 80/119
82. MySQLの面白いところ しかもなんかこれらの部品を組み替えたりしてなんかできた りする 81/119
83. MySQLの面白いところ 82/119
84. MySQLの面白いところ 83/119
85. MySQLの面白いところ 84/119
86. MySQLの面白いところ 85/119
87. MySQLの面白いところ yoku0825/bogus_redis_storage_engine yoku0825/zundoko_storage_engine: ズンドコキヨシ用 MySQLストレージエンジン 86/119
88. MySQLプロトコル でSQL以外の何か を語り掛けても結果 が戻ってくる 87/119
89. Query Rewrite Plugin Parserの手前を取るPre-parse Query Rewriteと Parserの後ろ(Optimizerの手前)を取るPost-parse Query Rewriteがある 88/119
90. クエリーリライト mysqlコマンドラインクライアントを起動してるのに、うっ かりlsとか叩いちゃったことありませんか？ mysql57> ls; +--------------+ | Tables_in_d1 | +--------------+ | t1 | +--------------+ 1 row in set, 1 warning (0.01 sec) mysql57> SHOW WARNINGS; +-------+------+-------------------------------------------------------------------+ | Level | Code | Message | +-------+------+-------------------------------------------------------------------+ | Note | 1105 | Query 'ls' rewritten to 'SHOW TABLES' by plugin: rewrite_example. | +-------+------+-------------------------------------------------------------------+ 1 row in set (0.00 sec) 89/119
91. クエリーリライト catとかお好きですか？ mysql57> cat t1; +-----+-------+ | num | val | +-----+-------+ | 1 | one | | 2 | two | | 3 | three | +-----+-------+ 3 rows in set, 1 warning (0.02 sec) 90/119
92. クエリーリライト サーバーサイドで書き換えているので、クライアントを選ばな い。 91/119
93. MySQLの面白いところ MySQLに格納されたデータを別のプロトコルでアクセスす る SQLをしゃべっているように見せかけて裏側は別のデータス トアを使う 書き込み効率重視のRocksDBをバックエンドにしたFacebook MySQLとか ‐ カラムナーでデータを格納するMariaDB Column Store(旧InfiniDB) とか ‐ 92/119
94. MySQLの面白いところ RDBMSの一つのポイントは「データの物理的な格納からの 抽象化」 オープンソースであることを差し引いても、「そこに敢えて手を入れ る」やり方がそもそも用意されている ‐ それどころかSQLである必要すらなくなったり 「さすが変態」 ©tmtms ‐ 93/119
95. 夢は無限大 94/119
96. MySQLで 楽しもう 95/119
97. 　 96/119
98. (ﾟдﾟ ) 97/119
99. ( ﾟдﾟ ) 98/119
100. ( ﾟдﾟ) 99/119
101. 時間余ってると思 うのでMySQLのト リビアを話します 100/119
102. MySQLの 正しい発音 101/119
103. マイエスキューエル 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 102/119
104. MySQLの 名前の由来 103/119
105. Myちゃん MySQL is named after co-founder Monty Widenius’s daughter, My. http://dev.mysql.com/doc/refman/5.7/en/history.html ただしMyちゃんの名前の発音は ミィ 104/119
106. MariaDBの 名前の由来 105/119
107. 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/ 106/119
108. 宿命のライバル（？）のツーショット http://www.slideshare.net/Codemotion/my-sql- 107/119
109. MySQLのロゴ 自重 https://www.mysql.com/jp/about/legal/logos.html 108/119
110. このイル カの名前 109/119
111. サキラまたはサキーラ The name of the MySQL Dolphin (our logo) is “Sakila,” http://dev.mysql.com/doc/refman/5.7/en/history.html 110/119
112. MySQLのロゴ 実は利用規定が厳しい というかまず使えない MySQL :: Logo Usage Guidelines 111/119
113. MySQL 5.0.96 なんて読む？ 112/119
114. MySQL 5.0.96 ごー てん ぜろ（れい） てん きゅーろく（きゅーじゅーろ く） ごー ぜろ きゅーろく（きゅーじゅーろく） あるいは他に 113/119
115. 5.0.96の意味 5 メジャーバージョン番号 0 リリースレベル 96 リリースシリーズ(メジャーバージョン番号とリリースレベル)内でのバージ ョン番号 http://dev.mysql.com/doc/refman/5.7/en/which- version.html 114/119
116. オレオレ認識 5.0 メジャーバージョン（正しくはリリースシリーズ） 96 マイナーバージョン 115/119
117. さっきから（？） 背景にいる この子 ⇒ 116/119
118. 日本MySQLユーザ会のロゴのマイナくん（仮） 日本MySQLユーザ会（略称: MyNA = MySQL Nippon Association） まいな、と読みます。 ‐ http://mysql.gr.jp/ 117/119
119. クラ〇ドワークスで発注して擬人化してもらった（真顔） 今でもなんであんなにムキになって舞奈たんを擬人化し たかったのか良くわかりません。 なお、舞奈たんは「マイナくん（仮）」の擬人化であっ てMySQLの擬人化ではないので、緑色です。 (snip) ちなみに「どこからその予算出てるの？」と聞か れることが何度かありましたが、俺のお小遣いです 日々の覚書: 舞奈たんとは何なのか 118/119
120. MySQL楽 しいよ！ 119/119