長崎県の右下の端っこに「オープンキャンプin南島原2017」に参加しにいった話

 知人の書き込みからその開催を知り、興味を持った「オープンキャンプin南島原2017」。長崎県は、左下のほう(長崎市とか)しか行ったことがなかったので、漠然と「右下にも行ってみたいなぁ」と思っていたことも、参加への思いを後押ししました。コロプラの位置登録もできるし。こうやって人々が新たな地を訪ねる原動力と(いまだに)なっているコロプラ*1、すごい(笑)。


f:id:sakaik:20170528180150p:plain:w200


 南島原市へは、公共の交通手段に難儀する(平たく言えば、電車などない*2)ため、空港に到着する遠隔地からの参加者のために、主催者が車でお迎えに来てくれます。それだけでも恐縮なのに、実はその時間に到着する便で来たのは私ひとりだけ。なんか、すいません!すいません!大恐縮です。次回以降参加する際は、なんとかします!

 ずっと海沿いを走り、最後に山側に向かってしばらく登っていくと、会場である「エコ・パーク論所原」に到着。広いよー、自然だよー、鳥がいっぱい鳴いているよー(幸せ)。夜は、こんなにたくさんの星を見たのは20年ぶりくらいか、というくらい星がきれいだったし。ちなみに、論所原は "ろんしょばる" と読みます。九州に来たぞーって感じ。

f:id:sakaik:20170521071727j:plain


 受付を済ませて、まずはセミナータイム。オープニングの後、南島原市サテライトオフィスを置いている(株)セラクさんのお話、地元IT勉強会の活動紹介などのお話、実体験(家が農業)に基づくIT利用へのアイデア耕作放棄地に関する情報交換と活用)のお話などを伺いました。
 学生さん、緩急取り混ぜて笑い要素も入れていて、プレゼン上手いなぁと感心しきり(構成の策定等の準備も含めて)。セラクさんはすっかり南島原市の「なかま」になっている様子がよく分かり、「補助金もらって支所だけ作りました」のようなアリガチなものとは一線を画しているとの印象を受けました。
 次に、日本Androidの会の進藤さんから Google I/O のお話。客層に合わせてわかりやすく説明されていて、見習いたい、見習いたい! Googleのサービス内容はとにかく AWSで感じていたのと同様に、サービスが細分化して大量増殖しているので、そろそろ階層化するなどわかりやすくまとめるフェーズに入ってもいいなぁと感じました。全体を知りたくても、もう途中から入れない(笑)。

f:id:sakaik:20170520145917j:plain 


 その後は、5~6人くらいずつのグループに分けられて、グループディスカッション。その日の夕方と翌日の午前と。
今回は学生さんが半分近く参加されていたので、グループ内も当然その比率。さしずめ 「オトナ 対 学生」の 3対3デートと表現すれば良いでしょうか。そうなると必然的に、オトナたちが張り切るわけです。自分の体験を伝えようとする人あり、学生さんから言葉を引き出す工夫を重ねる人あり、それぞれの方法で交流を進めました。うん、もうディスカッションとかじゃないんですけど、いいんです(笑)。こんな感じなので、所期のテーマである「IT」「地域」「人材」の中から、話題は自然と「人材」へ。
 私もオトナチームの立場から、偉そうに自分の体験を語ったりはしましたが、自分が彼らの年齢の頃を考えると、参加された学生さんたちみんな、本当にすごいなぁと思います。オトナ対学生だけでなく、学生同士でも、2年制のカレッジの2年生と、4年制大学の2年生の方々が参加されていて、同じ年齢なのに将来について考えている量が異なることに刺激を受けている様子を見て、本当に良い場だなぁと感じました。(来年社会人になる人と、あと3年ある人の差なので、ある意味当然ではありますが、それが良い刺激になったようでした)


 宿泊はケビンにて。アウトドアでない私は「ケビン」という用語を知らず、なぜか脳内では「円形の布状のテントで真ん中に太い柱があるやつ」を想像していたので、しっかりした建物で、ほっとするやら拍子抜けするやら。(それはゲルです・・・)

 f:id:sakaik:20170521073752j:plain


 気づいたら長くなってしまったので、いったんここで切ります。
続きはまた!






当日の模様は南島原市のページにも掲載されています。
www.city.minamishimabara.lg.jp

*1:正式には今は「プラス」が取れていますが呼び慣れたこの名で

*2:島原鉄道はあるけど今回の目的地とは離れている

日本MySQLユーザ会会 in 長野2017に行ってきた話

 ユーザ会代表のお膝元である長野でMySQLのイベントをやろうと言って、ようやく実現された本イベント。いや、2年くらい前だったかに一度やったのだけどタイミングが合わなくて参加できず、今回「ようやく」参加できたのは私の都合というべきか。

 nseg.connpass.com


 こういうイベントには、時間をゆったりと取れるようになるべくお泊まりで参加することにしている私ですが、今回はやや立て込んでいたこともあり、日帰りにて。22:08に長野駅を出る電車に乗れば余裕で帰れるって、新幹線すごい!


 MySQLユーザ会会(MyNA会)は、13:30開始。5人の登壇者が次々に発表しました。
私は、トップバッターで「MySQLとは」というお題にて。
おそらく参加者のほとんどは、このレベルのことは知っているだろう、という中でのこのテーマ。シナリオ設定に随分頭を悩ませましたが、「そもそもデータベースソフト(RDBMS)なんて使わなくてもいいじゃん」というところから話を始めることで、MySQLのようなRDBMSを使う意義を考えてもらうという趣向にたどり着きました。実際お話してみて、なかなか悪くない視点だと感じたので(自画自賛)、今後この視点をもう少し広げてみようかななどと思った次第。

 加えて、デモとして、AWSRed Hat上に(yumリポジトリを使わずに)MySQLが動作する環境を作るお話をさせていただきました。気楽に環境を作って壊すことができると、MySQLをいじくり倒すのが怖くなくなる(=ぐちゃぐちゃになったらまた最初に戻せる)ので、ぜひ、この方法でなくても良いけれども、皆さんそれぞれの「まっさら環境立ち上げノウハウ」を持ってもらえたらな、と思います。

 この2つの発表資料は、slide share に公開しています(本日記末尾に埋め込み)。



 他の方の発表では、最新情報や知らなかったお話などたくさん聞かせていただき、たいへん勉強になりました。
バグ報告No.199 (2003年)が MySQL 8.0でようやく14年越しで修正されたとか*1、 もっと古くはバグ報告No.2(2002年)が最近直った(笑)のに、8.0 でまた動かなくなってしまった問題(笑)とか、面白かったです。

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


 あとは、MySQL 8.0 でついに Window関数が入るとか(今後 laboで公開、and/or 8.0.3以降に含まれるかも)。予てより「SQLのお勉強をしたいだけなら、postgreSQL」とお勧めしていた根拠のひとつがこの Window関数の未実装だったので、これは大歓迎の大事件です!待ち遠しいです。これで、SQLの勉強をしたい人に胸を張ってMySQLをお勧めできるようになります。


 夜は懇親会にて盛り上がり。この場でもたくさんのお話を聞かせてもらえて、たくさんの経験や価値観を聞かせてもらえて、充実した時間でした。
 朝7時半に家を出て、24時半に帰宅という慌ただしいスケジュールでしたが、早めに現地について少し観光もできたし(これは別日記にて)頭と心を満腹にして、仲間たちと一緒の新幹線に乗って帰宅しました。楽しかった~。




www.slideshare.net

www.slideshare.net


@yoku0825さんの発表資料:「yoku0825を支える技術」
https://www.slideshare.net/yoku0825/ss-75941359


@bizstationcorpさんの発表資料:「Transactd PHP ORM」
https://www.slideshare.net/bizstation/transactd-php-orm


今回の発表資料ではないけどCTEやWindow関数について最新情報が載っている資料(梶山さんより紹介)
https://www.slideshare.net/oysteing/common-table-expressions-cte-window-functions-in-mysql-80


f:id:sakaik:20170513131913j:plain:w400

*1:InnoDB auto_incrementの値が保持されないことがある問題。具体的には、INSERT→DELETE→再起動で、次のauto_increment値が、現在あるデータの最大値+1になる=DELETEされたはずの番号が再利用される=問題。値をメモリ上にしか保持していなかったことに起因する。

AWSのセミナー「Technical Essentials」がとても良かったので語りたい

 AWSの "AWS Technical Essentials" 1 & 2 という有料の入門セミナー(トレーニング)に行ってきました。
1月までは「AWS実戦入門」1 & 2 というものだったようで、おそらく最新情報にリニューアルしたのでしょう。図らずも、その第一弾に参加できたことになります。
 ほぼ知識ゼロの状態からの受講だったので、かなり期待しての参加でしたが、そんな期待値が上がりきった状態でさえも「期待以上のものだった」と言わしめる程の満足度の高さでした。

AWS トレーニング | インストラクター主導 | AWS Technical Essentials 1
AWS トレーニング | インストラクター主導 | AWS Technical Essentials 2


私のスペック

  • IT業界暦はそれなりに長い
  • データベースは好き
  • ネットワークはよく分からない。見よう見まねでなんとなく触れる程度
  • レンタルサーバ(1台借りからVPSまで)は経験あるが「クラウド」と呼ばれる系には乗り遅れた感あり
  • まったくクラウドの世界観も雰囲気も分からず、雲を掴むような状態に、内心ちょっと焦っている
  • AWSなりAzureなりを、日常の中で誰かと一緒に学べる環境にない(詳しい人はいっぱいいるけど現場で一緒に作業したりの関係にはない)。話し相手がいない

私の集合研修に対する考え方

 大昔になりますが、いくつかの集合研修によく参加していた時期がありました。
正直なところ、満足したことはありませんでした。それは、その分野である程度自習してしまった後で行ったのでコースの半分以上は知っていることを聞かされたという時もありましたし、カリキュラム自体が素人目に見てもお粗末だったり、あるいは講師の話し方が気に入らなかったり(やたら「えー」と言うとか、語尾を上げるとか)など様々なケースがありますが、とにかく集合研修に対する私の印象は、「金銭的コストにも、時間的コストにも見合わないもの」でした。だから、もう何年も受講したことがなかったのです

今回受講したのは?

 「スペック」で自白したとおり、乗り遅れに対して相当な危機感を持っていましたので、入門者に教えてくれるものを探していました。ちょうどセミナーの内容がリニューアルするとのことで、最新情報を得られる感が強かったこともありますし、私が最大に信頼する、中の事情に詳しい知人に絶賛お勧めされたことも大きく影響しています。
 そして、私自身がAWSのサービスに対して「まったく白紙」だったこと。半端に知っているより、聞くこと全てが新鮮なほうが、いっぱい得るものがあってオトクな感じがしました(笑)。

それまでのAWSの知識、経験は?

 昨年12月末に、知人から「触ってみなよ」だったか「触ってみてよ」だったかお勧めされたことがキッカケで、それまで強い興味は持っていたので、大晦日にアカウント作って触り始めました。それから年始にかけて、EC2を「環境をすぐに作ってすぐに壊せる便利なレンタルサーバ」としてキャッキャ言いながら楽しんでいたのは、この日記を見ていた皆さんにはご存じのとおりです。
 当時は「やっと "AWS"に触るようになったぞ!」とウキウキしていたのですが、それはAWSの(重要ではあるけれども)ごく一部の機能であったことを、Essentialsセミナーを受講して思い知ったのでありました。Essentials セミナーの内容でさえ、AWSのごく一部なんですけどね。

2日続けての受講が良い?別々が良い?

 Technical Essentials 1 と Technical Essentials 2 はシリーズではありますが、それぞれ別個の講座なので、必ずしも2日続けてのスケジュールで参加する必要もありません。が、少々業務とかのスケジュールに無理をしてでも、2日続けての参加を強くお勧めします。
 続けて参加する人が多い(今回は多かった)ので、講師の話もそれらの人にある程度合わせて「昨日の話」を織り交ぜたりします。別段、「昨日の話」が分からなくても受講内容の本質に何も影響はないのですが、知らない側からすると「昨日はいったいどんな面白い話があったのだろう」と気になってしまう面もあると思います。2日連続の参加で、一気に理解と体験を深めるのが吉、と考えます。

セミナー全体の雰囲気や内容は?

 (有料セミナーの中身に関する話題なので、細心の注意を以て書いているつもりですが、不適切な内容がありましたらご指摘ください)
 セミナールームには1人1台のノートPCと19インチくらいのセカンドディスプレイが用意されています。自分で持って来たPCでも受講できたようですが、集中するために、私は用意されたPCを使う事にしました。(Facebook見たりメール確認したりしちゃう意志の弱い子ですw)
 Essential 1 は、主に座学を中心としてAWSの基本的なサービス群について学びます。実際のAWS環境を操作して、説明の内容を確かめてみたりする演習も少しだけあります。この「環境が用意されている」ということが非常に大切で、いま説明している機能がメニューのどのへんにあるか等、その都度確認しながら話を聞けるのが、快適でした。
 Essential 2 は、演習中心。先生が各演習の冒頭で、その演習の目的とポイントを説明してくれた後、30分~60分程度を各自で操作する時間として与えられます。テキストの手順説明はとても分かりやすいですし、不明点があれば質問もできます。早く終わっちゃってもそのまま実環境を触れるので、なんとなく読み飛ばしてきた設定項目を眺めてみたり、少し設定を変えたり追加してみたり。AutoScaling の演習で時間が余ったので、(演習では高負荷時にインスタンスを増やすものだけだったので)軽くなったら減らす指定を追加してみたのが個人的なハイライト。
 Essential 2は、最低限のlinuxコマンドライン操作の経験はあったほうがいいです。全コマンドを用意してくれているので、知らなくても進めることはできますが、コマンドを知っていたほうが、よりAWSの知識習得に集中できます。
 簡単なファイル操作(ls, cd, cp, mv, tail)、ネットワーク関係(ping, curl, wget)、その他(sudo, vi, exit) そして、sshでサーバに接続する方法(というか考え方)。tail に関連して grep -v をパイプでつなげてフィルタリングする方法くらいまでを知っていると、より快適かと思います。逆に言えばこの程度でOK。

 取り扱ったサービスは、こんな感じ(画像はAWSの「サービス」一覧に、私が赤印をつけたもの):
f:id:sakaik:20170209004320j:plain

 こうして見ると、まんべんなく体験してきた、良いカリキュラムだなと改めて思いました。
一方で、「思ったよりも少なく見えるな」と感じたのは、実はEC2の中にたくさんの(VPC,ボリューム,AutoScaling, network設定関係、セキュリティグループ、ロードバランサーなどなどの)技術が含まれているからです。盛りだくさんですEC2。



 こんな感じで2日間。居眠りすることもなく、途中で飽きて離席したくなることもなく、良い雰囲気で良いカリキュラムで良い先生で、とても充実していました。
 今回学んだことを軸として、より深く掘り下げていくと同時に、他のサービスも色々試して横幅も広げていきたいなと思います。


 そして「人様にものを教えていただく」って楽しい!!!!!
Webの情報では、まず最初に「どの程度その記事を信じて良いか」の判断をする必要があるのですが、まずその取捨選択自体が初心者にはできない。そういった点も含めて、この2日間で「ゼロからイチへ」、ひとりで頑張っていたら2日程度では得られなかったジャンプアップを得られたと感じています。
 受講してよかった。



ありがとうございました。

オープンソースカンファレンス(OSC)2017-Osaka 参画

 オープンソースカンファレンス2017大阪 (OSC2017-Osaka)に参加してきました。
https://www.ospn.jp/osc2017-osaka/

f:id:sakaik:20170128160124j:plain

今回のOSC大阪のMySQL関係、データベース関係は豪華メンバー。
オラクルのMySQLチームさんのブースと、日本MySQLユーザ会(MyNA)のブースそれぞれで出展し(スポンサーさんとコミュニティの違いがあるので階が分かれてしまいました)、オラクルブースには、最近『やさしく学べるMySQL運用・管理入門【5.7対応】』を書かれた梶山/山﨑の両氏が、
ユーザ会のブースには、木村氏(はお隣のFirebirdのブースでしたがMySQLのプロフェッショナル)と今回MySQLユーザ会枠のセミナーをしてくれた三谷氏に加えて末席に私が居ましたの。

 三谷さんのセミナー、早速資料を公開してくださっています。
mita2db.blogspot.jp

 大規模なサーバ群を管理している経験の中から、ハードウェアでの解決方法、レプリケーションでの解決方法、そして MySQL 5.7 で追加された「グループレプリケーション」のお話まで、とにかくデータを守るための話が満載でした。
(私は、脳内でずっとグループコミットの話だと勘違いして大きなハテナを浮かべたまま聞いてしまったので、あとでもう一度読まなきゃ)


 私は聞けなかったのですが、金曜日にはオラクルMySQLチームの山﨑さんのセミナーもあり、こちらも資料が公開されています。
MySQL最新情報(MySQL8.0 や Cluster 7.5など)のお話です。
https://www.ospn.jp/osc2017-osaka/pdf/OSC2017_Osaka_Oracle_MySQL.pdf



 ちなみに今回は電車で行って電車で帰ってきました。飛行機に乗りまくったのは去年だけのお話です(笑)。
まぁその「電車」も、ちょっとした工夫を楽しんだのですが、その話は後ほど「日常編」のほうにでも。


 三谷さん、初遠征でのセミナー、ありがとうございました。これからも各地でのご活躍を!

MySQLのテーブルのファイル名(記号を含むテーブル)

 ふと、「MySQLってテーブル名にハイフンを使用できたよな」と思い出したことから、「そういえばハイフンとマイナス(引き算)って混同しないのかな」と気になりました。
この疑問自体の答えは簡単で、
「そのまま記述すると問題のあるテーブル名はバッククォート(`)でくくる」
というだけなのですが、実際にOS側に作成されるファイルのファイル名が、以前と違っていたのがおもしろかったので、書いておきます。

mysql> create table `test-one` (a int, b varchar(20));

 としてテーブルを作成すると、

-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:31 test@002done.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:31 test@002done.ibd

 のようにファイルが作成されます。 @0002d がハイフンですね。

ということは他の記号も問題なく使える?

mysql> create table `test*two` (a int, b varchar(20));

 としてみました。

-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:52 test@002atwo.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:52 test@002atwo.ibd

 @0002a がアスタリスク記号ですね。

 他の記号も行けちゃいそうなので、試してみます。

mysql> create table `!"#$%&'()@[]*+:;/?,<>` (a int, b varchar(20));

 そもそも記号で始まっても良いのか?という疑問もありますが、やってみます。
 結果は・・・

-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:52 @0021@0022@0023@0024@0025@0026@0027@0028@0029@0040@005b@005d@002a@002b@003a@003b@002f@003f@002c@003c@003e.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:52 @0021@0022@0023@0024@0025@0026@0027@0028@0029@0040@005b@005d@002a@002b@003a@003b@002f@003f@002c@003c@003e.ibd

  おおお!!!!

 こんな名前のテーブル、使えるのかなって思いますよね。

mysql> insert into `!"#$%&'()@[]*+:;/?,<>` values (1,'mydata');
Query OK, 1 row affected (0.00 sec)

mysql> select * FROM `!"#$%&'()@[]*+:;/?,<>`;
+------+--------+
| a    | b      |
+------+--------+
|    1 | mydata |
+------+--------+
1 row in set (0.00 sec)

 なんの問題もありません! 使い勝手はともかくとして。


 マニュアルによるとクォートした場合は、識別子として

Permitted characters in quoted identifiers include the full Unicode Basic Multilingual Plane (BMP), except U+0000:

ASCII: U+0001 .. U+007F
Extended: U+0080 .. U+FFFF

だそうです。

MySQL :: MySQL 5.7 Reference Manual :: 10.2 Schema Object Names

MySQLのデータベース(スキーマ)に別名を付けるcreate_synonym_db

 昨日の 日本MySQLユーザ会会(MyNA会)で、yoku0825さんがお話の中で紹介してくれていた、create_synonym_db が面白かったので、記録しておく。曰く:


 sysスキーマの中にある create_synonym_db を使うと、データベースに別名を付けることができます。
この「データベース」というのは、CREATE DATABASE したりする、あの「データベース」ね。useしたりする、あれね。


例として紹介されていたのは、performance_schema という長ったらしい名前に p_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.21 sec)

 と実行すると、performance_schema の中にある87個のテーブルまたはビューに対して、p_s データベースの中にビューを作ってくれます。データベースリストを見ると p_s ができていることがわかります。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| mytest             |
| p_s                |
| performance_schema |
| sys                |
+--------------------+
6 rows in set (0.00 sec)


 もちろん、自分で作ったテーブルに対しても、別名を付けることができます。以下は、test データベースに対して t という名前でも利用できるようにしたもの。

mysql> call sys.create_synonym_db('test','t');
+------------------------------------+
| summary                            |
+------------------------------------+
| Created 1 view in the `t` database |
+------------------------------------+
1 row in set (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

mysql> show databases;                                                                                                                       
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| t                  |
| test               |
+--------------------+
6 rows in set (0.00 sec)


 この日記では「別名」と書きましたが、特別なエイリアス用の仕組みがあるわけではなく、ビューを作ってくれるもののようです。 テーブル/ビューの一覧を information_schema から見てみると判ります。

mysql> select table_schema, table_name, table_type FROM information_schema.tables;
+--------------------+------------------------------------------------------+-------------+
| table_schema       | table_name                                           | table_type  |
+--------------------+------------------------------------------------------+-------------+
| information_schema | CHARACTER_SETS                                       | SYSTEM VIEW |
| information_schema | COLLATIONS                                           | SYSTEM VIEW |
:
| p_s                | accounts                                             | VIEW        |
| p_s                | cond_instances                                       | VIEW        |
| p_s                | events_stages_current                                | VIEW        |
| p_s                | events_stages_history                                | VIEW        |
| p_s                | events_stages_history_long                           | VIEW        |
:
| performance_schema | accounts                                             | BASE TABLE  |
| performance_schema | cond_instances                                       | BASE TABLE  |
| performance_schema | events_stages_current                                | BASE TABLE  |
| performance_schema | events_stages_history                                | BASE TABLE  |
| performance_schema | events_stages_history_long                           | BASE TABLE  |
:
+--------------------+------------------------------------------------------+-------------+
369 rows in set (0.01 sec)

 また、そういう仕組みなので、synonym を作ったあとで CREATE TABLE したものは両方から見えるわけではないので、ちゅうい。



 ただ、character_set 等を保持してくれないみたいなのは、気になるところ。このサーバは character_set_server=utf8mb4 で動作させているので、 performance_schema が utf8 なのに、p_s が utf8_mb4 で作成されてしまっています。変換がかかるから問題ないような気もするけど、本来不要な変換が挟まることによるリスクが気になるのは、古き時代の単なるトラウマか。

mysql> select * FROM schemata;                                                                                                               
+--------------+--------------------+----------------------------+------------------------+----------+
| CATALOG_NAME | SCHEMA_NAME        | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH |
+--------------+--------------------+----------------------------+------------------------+----------+
| def          | information_schema | utf8                       | utf8_general_ci        | NULL     |
| def          | mysql              | utf8mb4                    | utf8mb4_general_ci     | NULL     |
| def          | p_s                | utf8mb4                    | utf8mb4_general_ci     | NULL     |
| def          | performance_schema | utf8                       | utf8_general_ci        | NULL     |
| def          | sys                | utf8                       | utf8_general_ci        | NULL     |
| def          | t                  | utf8mb4                    | utf8mb4_general_ci     | NULL     |
| def          | test               | utf8mb4                    | utf8mb4_general_ci     | NULL     |
+--------------+--------------------+----------------------------+------------------------+----------+
7 rows in set (0.00 sec)

#もしかして、bugs事案? もう誰かレポート済みかな。

MySQLのInnoDBって file_per_table がデフォルトになっていたのか!

 「趣味のMySQLユーザ」の時期が続いていたこともあって、実体験による情報よりも、すっかり耳年増になってしまいました。取り返すべく、AWSの環境*1を得たのをきっかけに、色々試し始めています。


 今回触っていて、「あれっ?」と思ったのは、CREATE TABLE したら、テーブルごとに idb ファイルができあがっていたということ。いわゆる「file per table」というやつです。
 従来 InnoDB は、my.cnf で指定した idbファイル群を全テーブルで共通して使用していました。
innodb_file_per_table 自体は MySQL 4.1.8 の頃から存在しているものなのですが、私の中ではイロモノ的なイメージのままだったので、これがデフォルトになっていることにびっくりしました。
 調べてみると、MySQL 5.5.6まででデフォルトオンになっていたのに、MySQL 5.5.7からオフにした経緯があったようで、このときに「なにかヨクナイことがあったのかな」という印象を持ったのかもしれません。
 今に繋がる流れとして、MySQL 5.6.6からは再度デフォルトオンになっていたようで、随分遅れての認識と相成った次第です。

mysql> create table test1 (a int, b varchar(10));                                                               
mysql> create table test2 (a int, b varchar(10));
mysql> create table test3 (a int, b varchar(10));


$ ls -la
total 436
-rw-r-----. 1 ec2-user ec2-user    67 Jan 25 05:58 db.opt
-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:38 test1.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:38 test1.ibd
-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:38 test2.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:38 test2.ibd
-rw-r-----. 1 ec2-user ec2-user  8578 Jan 25 06:38 test3.frm
-rw-r-----. 1 ec2-user ec2-user 98304 Jan 25 06:38 test3.ibd

*1:と言っても、すぐに作って壊せるレンタルサーバの環境という程度の使い方しかしていませんが