はじめに
やあ (´・ω・`)
ようこそ、バーボンハウスへ。
このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。
うん、「また」なんだ。済まない。
仏の顔もって言うしね、謝って許してもらおうとも思っていない。
でも、このタイトルを見たとき、君は、きっと言葉では言い表せない
「ときめき」みたいなものを感じてくれたと思う。
殺伐とした世の中で、そういう気持ちを忘れないで欲しい
そう思って、この記事をかいたんだ
じゃあ、注文を聞こうか。
というわけでmysqlをdisります。disるだけなので内容はありません。いいね?
mysql には罠がいっぱい
そうなんですよ罠がいっぱいなんですよ奥さん。
いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの!
MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォルト設定で使うべきだよね?
NO! デフォルトで使うとか死にてえのかおめえ!
mysqlのデフォルトでの運用は大変危険です。運良く稼働しても長期運用すると痛い目を見ます。
そんな甘い考えは今すぐ捨てろ
DBのチューニングや設定なんてやばくなってからでも十分間に合うしとりあえず動かすことが大事だよね
NO! そんな考えは捨てろ!いますぐ/etc/my.cnfをひらくんだ。悪いことはいわない今すぐ開いて設定しろ。
さてここまで読んだ皆さんはこう思っただろう「こいつ具体例出さないでなんなん?ちんちん!!!
よろしいならば具体的な話だ。
ストレージエンジンの話
mysqlに有名なものとしてはMyISAMとInnoDBがある。
最近はもっと色々あるっぽいけど中の人が勉強不足であんまり語れないので許してね!
さてストレージエンジンですが、MyISAMとInnoDBともにメリットやデメリットがあります。
とりあえずInnoDB選んどけばええんやで
MyISAMはテーブルロック方式で書き込みが発生するとテーブルをロックするため更新には不向きなストレージエンジンです。
そのかわりリードが早いため、参照が多いテーブル構成ではいかんなくパフォーマンスを発揮してくれることでしょう。
ただトランザクションなんてものは存在しないので、データの不整合や最悪データの欠落などが起きるリスクもあります。
でもねこれmysql 5.5 以前までは標準でMyISAMが選択されていたんですよ!奥さん!
おいおいMySQLクソじゃん。カスじゃんとおもった貴方!
そこでInnoDBなんですよ。こいつはなんと「行ロック」「トランザクション」を備えてるんですよ!!!
すごい!すごくない???
しかし行ロックだからといってデッドロックの恐怖はあります。
そこででてくるのが「ネクストキーロック」の話です。
ネクストキーロックの話をしだすと検証用のデータとか作らないといけないんで、
sh2さんの下記の内容をご参照ください。
2009-01-12 MySQL InnoDBのネクストキーロック おさらい
http://d.hatena.ne.jp/sh2/20090112
まあなんかその oracle には勝てなかったよって感じが伝われば幸いです。
もちろんネクストキーロックを限りなく防ぐ手立てがまったくないわけではないですが、
システムの設計により思わぬバグを生むのでシステム設計者とよくご相談の上ご検討いただければ幸いです。
この辺も合わせてご覧ください。
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
http://blog.kamipo.net/entry/2013/12/03/235900
ibdataの話
mysqlといえばこいつでしょう。もはや悪。だれだこんな仕様考えたやつは!
ibdata君は日に日に増大していきます。どれくらい増大するかというと最悪空き容量をすべて食いつぶします
わーい空き容量0%だたーのしー!首つるー!
なんてことになります。
さらにこいつに容量制限をかけることができますが、容量制限をかけた場合、その容量に到達した時点で
書き込めなくなります。つまりいきなりDBに反映されなくなります。たーのしー!
なおこれがmysqlデフォルトの挙動です。ふざけんな!!!!!
なおもちろんこれを防ぐオプションは用意されています。
「innodb_file_per_table」
忘れずに入れておきましょう。
これにいれるとテーブルの情報がテーブル毎に分割されるようになるので、容量が肥大化してもそのテーブルを削除するか、レコードを削除した後にalter table などのテーブルの再構築が走る操作を行うことでテーブル情報を縮小させることが可能になります。
なおこのオプションを有効にすることでパフォーマンスが低下するというデメリットもあるらしいですが、あきらかにそれを上回るメリットのほうが大きいので有効にすべきです(もちろんわかった上でこのオプションをつけないという選択も場合によってはありだと思いますけどね)
ちなみに一度肥大化したibdata君はこいつを消す以外容量を削減する方法はなく、無論こいつを消すということはDBのデータがすべて消し飛ぶということなので心臓に悪い作業を行う羽目になります。こわーい。
インストール時の話
mysqlもバージョンによって入れ方が若干変わる。
とりあえず同じ5系ならマイナーバージョンアップだしかわんねーべって考えは通じない。
バージョンにあった適切な導入の仕方を参考にしましょう。
バージョンアップの話
MySQL 5.7の罠があなたを狙っている
https://www.slideshare.net/yoku0825/mysql-57-51945745
すごくためになるスライドです。僕が言うまでもないって感じです。
ありがてえありがてえ・・・。
チューニングの話
mysqlでinnodbを長年使い続けている方ならもちろんご存知かと思いますが
「innodb_buffer_pool_size」の話です。
とりあえず脳死で総搭載メモリ量の80%くらいとっておけばいいです。
(もちろんスワップを発生させない範囲で)
この設定をちゃんとするかしないかでもDBのパフォーマンスは大きく変わります。
ほかにもパフォーマンスに影響するオプションは結構あるので要チェックデス!
文字コードの話
何も考えずにDBにつないでinsertとかするとlatin1ではいってしまったりします。
latin1で入った場合、そのまま扱う分には大きな問題に”あまり”ならないのですが、
ダンプして復元という話になってくると結構大きな問題になったりします。
mysqlをいれたあとはDBやテーブルを作るよりも先に文字コードの設定をすることをおすすめします。
もちろん「innodb_file_per_table」もわすれずにね☆ミ
インデックスの話
複合indexを貼る場合は順番が大事です。とりあえず貼ったからといって順番を逆にしたりするとindexは効力を一切発揮しません。気をつけてね。
具体例はそのうち。
最後に
でもぼかぁそんなmysqlが大好きなんだなぁ