書籍発行のお知らせ：詳解MySQL 5.7 〜進化したMySQLをよく知るためのテクニカルガイド〜
既に昨日のdb tech showcaseのスライドでご存じの方も多いだろうが、この度MySQL 5.7の新機能を解説するための書籍を発行させていただくこととなった。8月23日発売予定である。 MySQL 5.7の新機能については、これまでブログでは紹介してこなかった。というのも、あまりにもボリュームが多すぎて、ブログという媒体でカジュアルに紹介するには向いていないと思ったからだ。とはいえ、MySQL 5.7を皆さんに使っていただくには、誰かが新機能をしっかりと解説しなければならない。どうするべきか考えた結果、書籍としてまとめて出させていただくことになった。 新機能について真面目に解説しようとすると、新しいポイントがどこなのかということを言及するために、結局のところ元々の機能についてもある程度解説が必要になってしまう。そういうわけで、この書籍では、MySQLが持つ機能の基本的なコンセプトや
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
MySQL 5.6登場！！新機能速攻レビュー
現在、米国で行われているMySQL Conference & Expoにあわせて、新しい開発版であるMySQL 5.6が発表された。MySQL 5.5における新機能もかなりのものだったが、MySQL 5.6の進化は質・量ともに勝とも劣らない内容となっている。そこで、今日は簡単に、MySQL 5.6で追加された新機能の概要について見てみよう。開発版なので利用にあたっては十分な注意が必要（予期なく予定が変更される可能性あり）だが、次期正式版のリリースに向けて是非試してみて欲しい。 InnoDB関連MySQL 5.5で大幅な進化を遂げたInnoDBだが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
ヒゲモジャのギークが提案する技術習得戦略
先月、Dbtech Showcaseで松信さんがデータベース技術の羅針盤という講演をされた。残念ながらプレゼンそのものを観に行くことはできなかったが、その前の日に松信さんと一緒に昼飯を食べたとき、講演のあらすじについては伺っていた。その際にも同じようなことを松信さんには言ったのだが、スライドを見直した上で改めて自分の意見をまとめておこうと思ったので筆をとることにする。 なお、このエントリではスライドに書かれているトピックについて語るので、まだ松信さんのスライドを見てない人は先にスライドに目を通してから本エントリを読んで欲しいと思う。結論は全く違った方向に進んで行くが、その点は了承して頂きたい。 あなたに選択肢はあるか？ひと握りの天才なら自分の興味のある分野を開拓することができるだろう。あるいはすでに成功を収めた人であれば転職に困ることはないので、成功しそうな会社に乗り換えることもできるだろ
たった30秒でMySQLをコンパイルする方法 rev.2
もう2年以上前になるが、以前「MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック」というエントリを書いた。 エントリに書いた内容はそれなりにコンパイルの高速化に寄与はするが、実は測定方法は正しくなかった。このことについて、いつも冷静さを失わない奥一穂氏から、いつもの冷静さで指摘を頂いた。 奥さんの言う通りである。指摘をもらってから気がついた。反省した。それからからずっと「まっとうにコンパイルして30秒を切る方法」を模索してきた。そしてついに、ccacheを使わずにまっとうにMySQL 5.5のコンパイルを30秒未満で実行することが出来たので、その方法を紹介しようと思う。 速いマシンを買う いきなり身も蓋もない解決法だが、ぶっちゃけこれが一番効果的である。実行するべき処理が決まっていれば、最終的にCPUの実行速度によって処理時間が決まってしまう。 実は最近PCを新調したの
MySQLは立ち止まらない・・・MySQL 5.7開発版登場！
まだMySQL 5.6が登場して興奮冷めやらぬところだが、MySQLの開発チームはその手綱を緩めることはない。次期バージョンの開発版であるMySQL 5.7.1がすでに登場している。MySQLの開発リリースモデルではマイルストーンリリースと呼ばれるマイナーバージョンごとに新しい機能が盛り込まれる。（参照：MySQL 5.5登場）MySQL 5.6系での最後のマイルストーンリリース、つまり新しいバージョンが盛り込まれたバージョンがマイルストーン9、そして5.7.1がマイルストーン11となる。（マイルストーン10、つまり5.7.0はリリースされていないバージョンとなっている。）MySQL 5.7が正式版になるまでに、いくつのマイルストーンリリースを経るか、つまりどれだけ新機能が搭載されるかについては今のところ未定だが、新しいバージョンのリリースが待てない！という人はぜひMySQL 5.7.1を
紹介：【書籍】SQLアンチパターン
リレーショナルデータベースの父、エドガー・F・コッド氏が論文を発表したのは1970年。私が生まれる前の話である。そしてSQLがANSI標準になったのが1986年。RDBMSを、そしてSQLを使ったシステム開発は常に主流で在り続けたと言っても過言ではない。そんな歴史のあるSQLであるが、未だに多くの人はSQLを使いこなせて居ないように見える。 SQLはとても奥が深い。ソートやトランザクションが使用出来るおかげで、リレーショナルモデルを無視して単なるデータの入れ物として使ってもそれなりに便利だったりする。だが、それが今現在多くの悲劇を生んでいる原因でもある。多くの人が同じようにSQLを理解せず、そのため多くの人が同じ悲劇に見舞われる。そう、それがアンチパターンである！ 今回紹介するSQLアンチパターンは、洋書SQL Antipatternsの邦訳版だ。私は元々英語版のファンでであり、人々が陥り
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
最高の土管が欲しい
筆者は1年半ほど前に携帯のキャリアをドコモへ変更した。それまではソフトバンクを使っていたのだが、筆者の生活圏との相性が良くなかったようで、電波の状況が芳しくなかったのだ。ドコモへ変更してからは電波状況は満足のいくものとなった。しかし電波状況以外の問題で返って不満が募る結果となってしまった。なぜか？ひと言で表すとサービスに制約が多すぎるからだ。様々な不満を心に抱いていたところ、次のようなニュースが報じられた。 ドコモ社長「米アマゾンになる」 来年度からモバイル通販で野菜、健康機器など販売 - SankeiBiz（サンケイビズ） このニュースには閉口せざるを得ない。不満が爆発してしまいそうなので、ここらへんでひとつぶちまけてみようと思う。 IMEI規制 まず一つ目の問題は、それまで使用していたSIMロックフリー端末が使えなくなってしまったということだ。正確にいうと使用できるのだがデータ通信費が
ダウンロード刑事罰化について考える
先日、あろうことか国会において議員立法でダウンロードの刑事罰化の法案が可決してしまった。これは日本という国の発展にとって由々しき事態である。これはまさに日本の経済の発展にとって非常事態であると言っても過言ではない。しかしながら我々は今現在この日本で暮らしている真っ最中であり、ただ黙って日本が没落していくのを見ていくわけには行かないだろう。そこで、今回はダウンロード刑事罰化について、その問題点と我々が取るべき行動について論じてみようと思う。 これまで見ていたウェブページが見られなくなるか 我々にとって直接的に影響が出ると考えられるのはまずこの点だ。だが待って欲しい。我々はどうやってそのようなコンテンツを避けて通ればいいのだろうか。「このページの閲覧およびコンテンツのダウンロードは違法です」と宣伝しているウェブページがあるだろうか？あるファイルをダウンロードすることが違法だと判別するにはどうす
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
